Is line height determined by the first font in a CSS font stack?

Question

I ask this because when I try to create a CSS font stack for multi-language content, such as English and Chinese, the final rendering is affected by the first font in the stack (usually Latin ones, since most Chinese font comes with Latin support).

See this Codepen, for example.

div.a p {
    overflow: hidden;
}

p {
    background-color: red;
    border: 1px solid black;
    display: inline-block;
}

.chinese-only {
    font-family: "Hiragino Sans GB", sans-serif;
    font-size: 24px;
    line-height: 48px;
}

.english-chinese {
    font-family: "Avenir Next", "Hiragino Sans GB", sans-serif;
    font-size: 24px;
    line-height: 48px;
}

.chinese-english {
    font-family: "Hiragino Sans GB", "Avenir Next", sans-serif;
    font-size: 24px;
    line-height: 48px;
}

What I am seeing:

enter image description here

Since Chinese glyphs only appear in the Hiragino Sans GB, I expect all Chinese blocks to use the same line height. But they are apparently affected by adding the Avenir Next font at the top of the stack.

Since both Firefox and Chrome on OSX renders my example the same, I wonder if the CSS specification mentions anything about this. CSS 2.1 fonts spec doesn't appear to state what to do with line height when you fallback on missing glyphs.

Updated: Safari does render differently, but unfortunately the difference is due to overflow: hidden, not glyph fallback. My updated example may show this a bit clearer.

enter image description here

On Chrome and Firefox

enter image description here

On Safari

And if you are really into font-related headaches, try this example showing different font stacks, and see how they differ on each browser.

The CSS2.1 specification for `line-height` is not in section 15, but in [section 10.8](http://www.w3.org/TR/CSS21/visudet.html#line-height). — BoltClock, Mar 09 '15 at 16:51
@BoltClock the spec says "If more than one font is used (this could happen when glyphs are found in different fonts), the height of the content area is not defined by this specification." when all glyphs fallback to the second fonts, why is AD affected by the first font (I assume that's the root of my problem) — bitinn, Mar 09 '15 at 17:02
similar question: http://stackoverflow.com/questions/28363186/inline-elements-and-line-height, but the answer doesn't really answer: 1. why the spec says a UA can use em-box **or** ascender/descender (AD); 2. how do browsers decide on max/min em-box or AD when **glyph fallback** happens. — bitinn, Mar 10 '15 at 16:30
Hmm perhaps it's font-dependent or UA-dependent. Unfortunately I don't know enough about font metrics to answer definitively. — BoltClock, Mar 10 '15 at 16:33
Another explanation from Eric Meyer, http://meyerweb.com/eric/css/inline-format.html, if I understand correctly, my issue could be caused by UA trying to calculate line-box height using not only `Hiragino Sans GB` em-box, but also `Avenir Next` em-box... — bitinn, Mar 10 '15 at 16:39

score 4 · Accepted Answer · answered Mar 10 '15 at 18:50

This is pretty much going to come down to the user agents. Any time the CSS specification says, “not defined by this specification”, that’s code for “we’ll let browsers do whatever they think is best and then try to get them all to behave consistently after a few years of doing it differently”.

Furthermore, the latest CSS Inline Layout Module states right at the top of Section 1 (Line Heights and Baseline Alignment):

This section is being rewritten. Refer to section 10.8 of [CSS21] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.)

That’s from last month. So, you know, good luck and Godspeed, basically.

Interestingly, I see a different result in Safari 6.2.2 than you posted: test result

If there’s a difference between that and the latest Safari, you might be able to track down a bugfix between the two versions that explains why it changed.

I can't come up with a better explanation, mark this as the answer for now :) (though i realize safari 8 does render differently from other browsers, so my bad) — bitinn, Mar 10 '15 at 19:02
From the latest [CSS Inline Layout Module Level 3](https://www.w3.org/TR/css-inline-3/#inline-height) explains about a `strut` (an invisible glyph of zero width) with the metrics of the box’s first available font. — User 28, Dec 11 '20 at 12:13

Is line height determined by the first font in a CSS font stack?

1 Answers1