[css21][css-inline] behavior differences when the primary font does not contain U+0020

[frivoal]

This is part of the #1796 series. Read that issue for context

Test source
Ref source
Live test
Live ref

If a inline-level box contains only characters from fallback fonts, we've got two different behaviors, plus a bug: * Edge and Safari: size the height of the inline-level box using the metrics of the fonts actually used **plus** the metrics of the primary font, even if it is not used. I.E. they take the strut into account. * Chrome: size the height of the inline-level box using **only** the metrics of the fonts actually used. I.E. it does not take the strut into account. * Firefox has multiple behaviors it randomly switches between. In the test linked to above, FF does the same as chrome, but if you load the Firefox Torture test linked to bellow, it will randomly exhibit multiple behaviors as you reload the page. This is clearly a bug, but does not clearly indicate what behavior is intended.

I suggest we align with Edge & Safari.

Edit: this test file is exposing more subtle things that I initially thought. See next comment for details.

---

Firefox torture test:
Test source
Live test

[frivoal]

There are some behavior differences when the primary font does not contain U+0020.

I stumbled upon this as an artifact of how I was building my test cases, specifying very limited unicode-range descriptors to artificially craft fonts with a limited range to activate font fallback.

In all the test related to #1796 I ran, the presence or absence of U+0020 in the primary font made no difference to Safari and Edge.

In most cases, it made no differences to Firefox either, except that for one case, where it triggers a clear bug: compare this with that. The first test is the same as the second one, except that U+0020 is removed (via unicode-range) from the primary font. Firefox will randomly exhibit multiple behaviors as you reload the page. Unstable layout is undoubtedly a bug, so I'll report this to Mozilla, but we don't need to consider it from a spec point of view.

More interestingly from a spec point of view, in Chrome, the absence of U+0020 in the primary font triggers a different behavior in a few cases:

---

with U+0020	without U+0020
Test source Live test	Test source Live test

If U+0020 is missing from the primary font, the position of the baseline in a line-box with a non-normal line-height stops depending on the primary font (and continues not to depend on any fallback font either). I am not 100% sure where Chrome take its alternative value from.

---

with U+0020	without U+0020
Test source Live test	Test source Live test

If U+0020 is missing from the primary font, the position of the baseline within an inline level box with the line-height:normal and in a inline-level box with the line-height property manually set to the height you'd get with line-heigh:normal (assuming only the primary font is used) are no longer the same (unlike #1801). line-height:normal sizing and baseline alignment seems unaffected, which puts the two baselines out of sync due to the previous point.

---

with U+0020	without U+0020
Test source Live test	Test source Live test

In Chrome, if U+0020 is missing from the primary font, size the height of the inline-level box using only the metrics of the fonts actually used: in other words, Chrome does not take the strut into account in that case.

---

Fonts without U+0020 are odd corner cases, more likely found in test cases than in real sites, but it seems that authors could inadvertently fall into the same case as me when trying to use unicode-range to select a limited subset of characters out of a font. Anyway, It would be good to harmonize all browsers.

Is there something special in fonts / open-type about U+0020 that legitimizes Chrome's behavior, or some use case that depend on it? Otherwise, I think we should consider the Chrome behavior to be merely a bug, to be fixed by looking at some other glyph than U+0020 to figure out the metrics of the font / strut.

[frivoal]

Follow up, related to #1804: As can be seen by comparing this test that has U+0020 in the primary font to that one that doesn't, Chrome (and no other browser) also has a behavior difference regarding the height of the content area: If the primary font does not contain U+0020, the height of the content area stops depending on metrics of the primary font (and continues not to depend on any fallback font either).

[frivoal]

Further follow up: if U+0020 is missing from the primary font and no glyph from the primary font are used, then:

• Related to [css21][css-inline] height of the content area of inline level boxes #1804, Edge is the only browser that continues to determine the height of the content area of inline boxes using metrics of the primary font (current safari does too, but nightly safari does not). See this test that has U+0020 in the primary font to that one that doesn't
• Related to [css21][css-inline] Position of the baseline inline-level boxes with non normal line-height #1801, Firefox joins Chrome, and the position of the baseline in a line-box with a non-normal line-height stops depending on the primary font (and continues not to depend on any fallback font either). Safari and Edge continue to use the primary font metrics. See this test that has U+0020 in the primary font to that one that doesn't

[frivoal]

Note: As I don't know how to create fonts, I do not know what would happen if instead of excluding U+0020 from the font using unicode-range, we used a font which didn't have that glyph at all in the font file. Maybe the same, maybe not. This is possibly worth checking. Maybe @litherum can help here.

[kojiishi]

1. If U+0020 is missing from the primary font, the position of the baseline in a line-box with a non-normal line-height stops depending on the primary font (and continues not to depend on any fallback font either). I am not 100% sure where Chrome take its alternative value from.

Isn't this something we just resolved in #1765? Blink doesn't use fonts whose unicode-range does not contain U+0020 as the first available font. Since your test doesn't contain other fonts, it's the same as no fonts found, and Blink use the users' preferred font, or last resort system font if it's missing.

3. Chrome does not take the strut into account in that case.

I think the question is "the strut" of which font. Since the strut should come from the first available font, and with #1765, fonts that don't have unicode-range U+0020 are not the first available font, we take strut from the users' preferred font or the system font.

I haven't really understood all test cases you created yet, sorry, but does this answer your question? If you have further question, or any specific case you think it's a Blink bug, please let me know.

[frivoal]

Isn't this something we just resolved in #1765?

Possibly, yes. It looks that I had missed that. Either way, browsers differ. So if we want to confirm the resolution taken in #1765, everybody other than chrome has to change. From the minutes in #1765, it is not clear to me that there was an understanding that that resolution implied that everybody needed to change.

Personally, I don't care strongly either way, as long as we're all clear what the expected behavior is, and all implement the same.

> I think the question is "the strut" of which font. Since the strut should come from the first available font, and with #1765, fonts that don't have unicode-range U+0020 are not the first available font, we take strut from the users' preferred font or the system font.

If we maintain #1765, that seems reasonable, but is that specified anywhere? I could also imagine taking the strut from the parent element, from example. Do you mean going through the fallback chain, and reaching the system fonts that way (which would mean it could still depend on things like language), or did you mean some other way to fall back onto the system font?

Edit: I re-read the fonts spec, and it answers this. Disregard this part of my comment.