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:

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.

On Chrome and Firefox

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.

Answer 1

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:

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.