Text Rendering

A recent addition to CSS is text-rendering, which is actually an SVG property that is nevertheless treated as CSS by supporting user agents. It lets authors indicate what the user agent should prioritize when displaying text.

The values for optimizing speed and optimizing legibility are relatively self-explanatory, indicating that drawing speed should be favoured over legibility features like kerning and ligatures (for optimizing speed) or vice versa (for optimizing legibility).

The precise legibility features that are used to optimize legibility are not explicitly defined, and the text rendering often depends on the operating system on which the user agent is running, so the exact results may vary. Figure 1-35 shows the results of optimizing legibility in various browsers.

As you can see in Figure 1-35, the differences between optimized and non-optimized text are objectively rather small, but they can have a noticeable impact on readability.

The value geometric precision, on the other hand, directs the user agent to draw the text as precisely as possible, such that it could be scaled up or down with no loss of fidelity. You might think that this is always the case, but not so. Some fonts change kerning or ligature effects at different text sizes, for example, providing more kerning space at smaller sizes and tightening up the kerning space as the size is increased. With geometric precision, those hints are ignored. If it helps, think of it as the user agent drawing the text as though all the text is a series of SVG paths, not font glyphs.

Even by the usual standards of standards, the value auto is pretty vaguely defined in SVG:

...the user agent shall make appropriate tradeoffs to balance speed, legibility and geometric precision, but with legibility given more importance than speed and geometric precision.

That’s it: user agents get to do what they think is appropriate, leaning towards legibility. In practice, things are more complicated. As an example, WebKit (as of mid-2013) seems to treat optimize legibility and geometric precision as the same, while the auto is equivalent to optimize speed. In the former case, WebKit enables a series of font features in order to increase the legibility; these are disabled for optimizing speed and auto. Gecko, on the other hand, is reported to treat auto as optimize speed for text sizes at or below 20px, and as optimize legibility for sizes above 20px.

The Height of Lines

The line-height property refers to the distance between the baselines of lines of text rather than the size of the font, and it determines the amount by which the height of each element’s box is increased or decreased. In the most basic cases, specifying line height is a way to increase (or decrease) the vertical space between lines of text, but this is a misleadingly simple way of looking at how line height works. line-height controls the leading, which is the extra space between lines of text above and beyond the font’s size. In other words, the difference between the value of line height and the size of the font is the leading.

When applied to a block-level element, line height defines the minimum distance between text baselines within that element. Note that it defines a minimum, not an absolute value, and baselines of text can wind up being pushed further apart than the value of line height. line height does not affect the layout for replaced elements, but it still applies to them. 

Constructing a line

Every element in a line of text generates a content area, which is determined by the size of the font. This content area in turn generates an inline box that is, in the absence of any other factors, exactly equal to the content area. The leading generated by line height is one of the factors that increases or decreases the height of each inline box.

To determine the leading for a given element, simply subtract the computed value of font size from the computed value of line height. That value is the total amount of lead. And remember, it can be a negative number. The leading is then divided in half, and each half-leading is applied to the top and bottom of the content area. The result is the inline box for that element.

As an example, let’s say the font size (and therefore the content area) is 14 pixels tall, and the line height is computed to 18 pixels. The difference (4 pixels) is divided in half, and each half is applied to the top and bottom of the content area. This creates an inline box that is 18 pixels tall, with 2 extra pixels above and below the content area. This sounds like a roundabout way to describe how to line height works, but there are excellent reasons for the description.

Once all of the inline boxes have been generated for a given line of content, they are then considered in the construction of the line box. The A-line box is exactly as tall as needed to enclose the top of the tallest inline box and the bottom of the lowest inline box. Figure 1-11 shows a diagram of this process.

Assigning values to line-height

Let’s now consider the possible values of line height. If you use the default value of normal, the user agent must calculate the vertical space between lines. Values can vary by the user agent, but they’re generally 1.2 times the size of the font, which makes line boxes taller than the value of font size for a given element.

Most values are simple length measures (e.g., 18px or 2em). Be aware that even if you use a valid length measurement, such as 4cm, the browser (or the operating system) may be using an incorrect metric for real-world measurements, so the line height may not show up as exactly four centimeters on your monitor.

em, ex, and percentage values are calculated with respect to the font-size of the element. The markup is relatively straightforward, and the results are shown in Figure 1-12:

Warning

Length alignment

Finally, let’s consider vertical alignment with a specific length. vertical-align is very straightforward: it shifts an element up or down by the declared distance. Thus, vertical-align: 5px; will shift an element upward five pixels from its unaligned placement. Negative length values shift the element downward. This simple form of alignment did not exist in CSS1, but it was added in CSS2.

It’s important to realize that vertically aligned text does not become part of another line, nor does it overlap text in other lines. Consider Figure 1-22, in which some vertically aligned text appears in the middle of a paragraph.

As you can see, any vertically aligned element can affect the height of the line. Recall the description of a line box, which is exactly as tall as necessary to enclose the top of the tallest inline box and the bottom of the lowest inline box. This includes inline boxes that have been shifted up or down by vertical alignment.