Em's for Line-Height

EM's for line-height

Assuming that “converting to ems” means using the em unit for font-size, then you should set line-height in a manner that also adapts to the font size. The two properties are closely related, and if you set one of them in em and the other (e.g.) in px or pt, then the page will break if the font size is changed. So it would work against the very idea of “using ems” to use essentially different units for essentially connected properties.

For example, if you set font-size: 1.5em and line-height: 18px, then things will depend on the font size of the element’s parent and may go very wrong if that size is much smaller or much larger than expected.

Whether you use the em unit or a pure number is a different issue. Using just a number, as in line-height: 1.2, is primarily equivalent to using the em unit, as in line-height: 1.2em. But there is the difference that when line-height is inherited, it is the pure number that gets inherited, not the computed value.

For example, if an inner element has twice the font size of its parent, then the inherited value 1.2 means that 1.2 times its own font size is used, which is OK. But if the parent had line-height: 1.2em, then the child would inherit a value that 1.2 times the parent’s font size – which is much smaller than its own font size.

for more explanation end examples see line-height @ Mozilla Developer Network

How does 'line-height' in ems get calculated in this scenario?

This happens because the span is inline and thus its text is affected by the surrounding line height (that of the p). If you set the span to display:inline-block it will be the same.

span, p {

   line-height: 2em;

   font-size: 14px;

}

p span{display:inline-block;}

<p style='font-size: 16px;'><span style="font-size: 12px;">Candidates will be given a hypothetical psychological report in which relevant background information (i.e., country of origin, primary language spoken in the home, and length of time living in the U.S.) and assessment data will be detailed.Candidates should demonstrate an increasing understanding and knowledge of CLD concepts and issues within the reports. Based on information provided candidates are to complete the report incorporating the following:</span>

</p>

<span style="font-size: 12px;">Candidates will be given a hypothetical psychological report in which relevant background information (i.e., country of origin, primary language spoken in the home, and length of time living in the U.S.) and assessment data will be detailed.Candidates should demonstrate an increasing understanding and knowledge of CLD concepts and issues within the reports. Based on information provided candidates are to complete the report incorporating the following:</span>

Adjusting line-height for different ems in stacked text?

This is a side-effect of the markup used. Replace the line breaks (<br>) with block-level containers to achieve the desired behavior (stack the words on one another), e.g.:

HTML

<div>THIS</div>
<div>IS AN</div>
<div class="important">important</div>
<div>SENTENCE</div>​

You can also lose the line-height declaration, as it no longer serves a purpose:

CSS

body {
    font-size: 8em;
}
.important {
    font-size: 0.5em;
}​

References

• A live demo on dabblet
• HTML block level elements on Mozilla Developer Network

---

Note: You may use any block level elements, e.g. div containers or p elements. Paragraphs will be more appropriate semantically, but you should be aware of any default styles applied to them such as thick padding, bottom margins etc..

Why does unitless line-height behave differently from percentage or em in this example?

Based on clues in the proposed answers, I think the rendering behavior seen in these examples is counterintuitive, but correct, and mandated by the interaction of several rules in the spec, and the overall CSS box model.

1. CSS calculates the leading L needed for a box by the formula
   line-height = L + AD, where AD is "the distance from the top to
   the
   bottom"
   of the font. Then "half the leading is added above A and the other
   half below D." So text that has font-size:16px and
   line-height:24px will have 4px of leading above and below. Text
   that font-size:8px and line-height:24px will have 8px of leading
   above and below.

2. By default, however, "user agent must align the glyphs ... by their
   relevant
   baselines.".
   This starts to explain what's happening here. When line-height is
   specified by percentage or em, a computed value is inherited by the
   child (here, the smaller span). Meaning, the smaller span gets
   the same line-height as the parent block. But because of the L +
   AD formula, the text of that span has more leading on the top and
   bottom, and thus the baseline sits higher in its box. The browser
   pushes down the smaller span vertically to match the baselines.

3. But then the browser has a new problem — how to deal with the line
   spacing in the enclosing block, which has been disrupted by this
   baseline-adjusting process. The spec resolves this too: the
   line-height of a block-level element "specifies the minimal
   height of line boxes within the
   element".
   Meaning, CSS makes no promise that you'll get your exact
   line-height, just that you'll get at least that amount. So the
   browser pushes the lines apart in the enclosing block so that the
   realigned child box will fit.

The reason this is counterinitutive is that it's the opposite of how most word processors and page-layout programs work. In these programs, a smaller stretch of text within a paragraph is aligned by its baseline (like CSS) but line height is enforced as a distance between baselines, not as a box surrounding the smaller text. But that's not a bug — CSS is designed around a box model. So in the end, we could say that this spacing behavior is a consequence of that model.

That still leaves us to explain the behavior in the example with the unitless line-height:

1. First, note that when no line-height is specified, the browser
   will apply a unitless line-height by default. This is required by
   the
   spec:
   the initial value of line-height is normal, which is defined to
   have "the same meaning as <number>", and the spec recommends a
   value "between 1.0 and 1.2". And that's consistent with what we see
   in the examples above, where the paragraphs with line-height: 1.5
   have the same behavior as the paragraphs with no line-height setting
   (i.e., they are impliedly getting line-height: normal)

2. As others have pointed out, when the paragraph has
   line-height: 1.5, the calculated line-height of the paragraph is
   not inherited by the smaller span. Rather, the smaller span
   calculates its own line height based on its own font size. When the
   paragraph has line-height: 1.5; font-size: 14px, then its
   calculated line height is 14px * 1.5 = 21px. And if the smaller
   span only has the property font-size: 50%, then its font size is
   14px * 50% = 7px, and its line height is 7px * 1.5 = 10.5px (which
   will generally be rounded to a whole pixel). But overall, the
   smaller box is half the size of the surrounding text.

3. As before, the browser will vertically align the smaller span to
   the adjacent baseline. But this time, because the box around
   smaller is shorter than the surrounding text, this realignment
   doesn't have any side effects in the enclosing block. It already
   fits, so there's no need to spread the lines of the parent paragraph, as
   there was before.

Both cases represent a consistent implementation of the spec. That's good news, because it means we can predict the line-spacing behavior.

That brings us back to the original reason for this question. While I now understand that the CSS box model requires this behavior, as a practicing typographer, this is rarely the behavior I want. What I want is for the lines within a paragraph to have consistent & exact line spacing, even if some spans of text within that paragraph are smaller.

Unfortunately, it seems there's no way to directly enforce exact line spacing in CSS as one can in a word processor or page-layout program. Again, this is because of the CSS box model: it doesn't use a baseline-to-baseline line-spacing model, and line-height is specified to be a minimum measurement, not maximum.

But we can at least say that unitless line-height values produce the best approximation of exact line spacing in CSS. Fussy typographers like myself should feel comfortable using them, because unitless values are endorsed by the spec, and they produce consistent results across browsers. They are not a hack, nor are they deprecated.

The caveat is that they're still only an approximation. Unitless line-height values don't change the underlying CSS box model, nor the CSS box-positioning rules. So it's possible that in some edge cases, they won't have the intended result. But eternal vigilance is the price of good typography. Be careful out there.

What's the difference between em units and percents?

OK, so I've decided to sum up the answers.

• line-height's percentage value is relative to the current font-size.
• em units is always relative to font-size.
• Percents depends on context. For example, if they're used in font-size, they will be relative to the current font-size; if it's in height, they will be relative to the height.
• It changes a little bit when parent tag has font size declared as "small", "medium" or "large", because values of these are affected by browser's setting. In this context 1em == 100%, 1em seems to make setting a bit more "small" or a bit more "large" than 100%, read about it here

What are pros and cons to use 'em' sizing unit for width, height, padding, margin, line-height in fixed width layouts?

The biggest downside is in indentation and text-block alignment with fonts of different sizes with em-sizing. It gets hard to line things up exactly – if that's important to you (and it should be).

What is the CSS height of a line of text? It doesn’t seem to be 1em

The exact calculation of heights of lines is complicated (see CSS 2.1 section 10 Visual formatting model details), but in a simple case like this, the height is determined by the line-height value when the element is not empty. When it is empty, the height would be empty, but the min-height setting forces the height to the font size (1em).

The initial value of line-height is browser-dependent, and it is expected to depend on the font, too. The default is in practice always larger than the font size. This explains what happens here.

To keep the height constant, it is best to explicitly set its line-height and to set min-height to the same value, e.g.

#changeme {
    line-height: 1.25em;
    min-height: 1.25em;
}

Note: The em unit means the size of the font, which is by definition the height of the font. This is a reference quantity and does not normally correspond to the height (or width) of any letter; the height of most letters is smaller than the font size (though this varies by letter and by font).

---

Related Topics