[css-fonts] Reconsider the definition of "first available font"

[jfkthame]

The spec currently says:

The first available font, used for example in the definition of font-relative lengths such as 'ex' or in the definition of the 'line-height' property is defined to be the first available font that would match the U+0020 (space) character given font families in the 'font-family' list (or a user agent’s default font if none are available).

I recently landed a patch to make Gecko conform more closely to this behavior, but backed it out because it caused significant regressions. On looking into things, I think the behavior specified here is not in fact desirable or helpful, and should be altered.

The problem arises because of the text "that would match the U+0020 (space) character". This, by any logical reading I can think of, means that a font that does not support U+0020 is not eligible to be considered the first available font, and therefore the next in the list (or the browser's default) must be used as the basis for 'ex' or line-height computations.

This leads to poor behavior when a site does something like

.foo {
    font-family: "my-icons", "Blank";
}
@font-face {
    font-family: "my-icons";
    src: url("my-icons.woff2") format("woff2");
}
@font-face {
    font-family: "Blank";
    src: url("data:font/opentype;base64,T1RUTwAKAIAAA ....");
}

(this is simplified from CSS on tumblr.com), where "my-icons" is an icon font that supports only a set of PUA codepoints; it does not have any regular ASCII characters, not even <space>; and "Blank" is the Adobe Blank font in base64 format. It's presumably used here to avoid the PUA codepoints for the icons getting rendered as hexboxes/last-resort glyphs/tofu/whatever while waiting for the real icon font to load.

However, when the browser needs to refer to the ascent and descent of the first available font during computation of leading and half-leading, or to resolve a font-relative unit such as 'ex', it should -- if it accurately implements this part of the spec -- ignore the "my-icons" font, because that font does not "match the U+0020 (space) character", and therefore it must look at "Blank" to get the metrics to use.

This is unfortunate in this example because "Blank" has a 'cmap' table that maps all one million-plus possible Unicode codepoints to its 2K empty glyphs, and although the font data is not especially huge, it may take a long time to load this font.

It would be similarly unfortunate if the second font were a large webfont resource that would end up getting downloaded only to provide the size of the 'ex' unit (for example), or the normal line height of an empty element. But that seems to be what the spec text requires.

My testing indicates that browsers currently do use metrics from the "my-icons" font in an example like this, contrary to the spec. If the @font-face rule is given a unicode-range descriptor that excludes U+0020, then they do not treat it as the first available font, which corresponds with the cases discussed in #1765.

I think the problem is that in addressing the earlier issue, the spec text defining first available font was written in such a way that it appears to care about actual character support in the font, whereas what was really of interest was potential character coverage as specified by unicode-range.

My suggestion, therefore, is to modify the definition quoted above to something like:

The first available font, used for example in the definition of font-relative lengths such as 'ex' or in the definition of the 'line-height' property is defined to be the first available font that is not excluded by a unicode-range descriptor from matching the U+0020 space character, given font families in the 'font-family' list (or a user agent’s default font if none are available).

A webfont without an explicit unicode-range descriptor, or a locally-installed font used directly via font-family: <name>, will always be eligible to be the first available font, regardless of whether it supports U+0020 or not. Only webfonts that explicitly (using unicode-range) declare their non-support for U+0020 will be excluded.

[svgeesus]

Related: #1800 #1804 and

WebKit doesn’t do this; it just uses the primary font, and if the primary font doesn’t support “0” then it uses that font’s .notdef glyph. No downloads necessary.

and

[So my preference would be an ordered list of things to try:

• the width of the "0" glyph. if it doesn't have one,
• the width of the .notdef glyph. if it doesn't have one (and thus, the font is broken),
• use 0.5em]([css-values] ch units shouldn’t cause font downloads #3135 (comment))

[svgeesus]

I am supportive of the specific text proposed by @jfkthame but would like to hear from other implementers

[kojiishi]

Blink's logic is in FontFallbackList::DeterminePrimarySimpleFontData:

    if (font_data->IsSegmented() &&
        !ToSegmentedFontData(font_data)->ContainsCharacter(kSpaceCharacter))
      continue;

and as far as I can read from our code, SegmentedFontData::ContainsCharacter does not seem to check cmap.

@jfkthame, do you have a simple test case I can double check? /cc @drott

[jfkthame]

@kojiishi See http://wpt.live/css/css-values/ex-unit-004.html. This was designed to test the behavior as currently written in the spec: it uses the ex unit on an element where the first font listed in font-family is a font that does not include a space character and therefore (per current spec) should not be used as "first available font". All browsers currently fail this test -- they do use the test font as the basis for ex.

Adding a unicode-range: U+78; descriptor to the @font-face rule that loads the ExTestNoSpace font in that test makes it pass in both Firefox and Chrome, as they then do ignore that font for "first available font" purposes; this is the behavior I'm suggesting the spec should require.

[kojiishi]

See http://wpt.live/css/css-values/ex-unit-004.html

Thank you, confirmed the code above does not check cmap, only checks unicode-range.

[faceless2]

@jfkthame's proposal works for us, for what that's worth.

For reference I want to flag up issue with the related test http://wpt.live/css/css-values/ch-unit-017.html which is - as currently specified - incorrect, because the font being used for font metrics doesn't include the space character. This change proposed in this issue would make that test work as described.

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts] Reconsider the definition of "first available font", and agreed to the following:

• RESOLVED: Amend our algo for selecting first available font to check for the 0 glyph, if not there check for notdef glyph, else use 0.5em
• RESOLVED: Remove previous resolution, discussion continues on github

The full IRC log of that discussion

<dael> Topic: [css-fonts] Reconsider the definition of "first available font"
<dael> github: https://github.com//issues/4796
<dael> chris: Not all fonts have glyph for space which means not first available font
<dael> chris: Prop is a three way thing where thirds is width of notdef glyph which all fonts are required to have
<dael> astearns: I see that's 2nd on list
<dael> chris: Yes, sorry
<dael> astearns: If notdef is guar?
<dael> TabAtkins: Required and there are different. I'm happy with this
<dael> astearns: Is it what browsers impl?
<dael> chris: We believe so
<dael> chris: There's a WPT that's wrong right now but it would become correct with this change. I suspect that means browsers do what this is proposed
<dael> astearns: Prop: Amend our algo for selecting first available font to check for the 0 glyph, if not there check for notdef glyph, else use 0.5em
<dael> astearns: Objections?
<dael> RESOLVED: Amend our algo for selecting first available font to check for the 0 glyph, if not there check for notdef glyph, else use 0.5em
<dael> chris: My proposal is in the issue comments
<dael> fantasai: I think ti's different then original proposal so wondering if he was okay. I've got your proposal and one from Johnathan
<dael> chris: Right, his inclues unicode range so if the unicode range excludes space. Not about if font excludes space then it counts as not having one.
<dael> astearns: And if you use unicode range you exclude notdef so it falls to 0/5em
<dael> chris: notdef isn't excludable with unicode range
<dael> fantasai: resolution defines ch unit but first available font is a lot more general. I'm a little confused. 4796 from what I understand is the new definition is first space checking for first space. He prop not checking if there's a space but if unicode range on font would cover space character. THen you prop check for 0
<dael> chris: Not quite. If it doesn't have a 0 then you can use notdef glyph rather then say we fail. That's compat with webkit
<dael> fantasai: So to find first available font I check for a space, then for a 0, then notdef glyph, then use 0.5em? 0.5em is not a font.
<dael> chris: Right. I see what you're saying.
<dael> astearns: Talking about how to determine a measure from a first available font without a space or a 0 or notdef
<dael> fantasai: ch has a definition of use 0 or 0.5em. If you're looking for x there's other metrics. Here we're looking for what font file.
<dael> astearns: We're over-time. We should undo previous resolution and bring up later
<dael> RESOLVED: Remove previous resolution, discussion continues on github

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts] Reconsider the definition of "first available font" #4796, and agreed to the following:

• RESOLVED: The first available font is the first font in the font-family list whose unicode includes the space glyph

The full IRC log of that discussion

<dael> Topic: [css-fonts] Reconsider the definition of "first available font" #4796
<dael> github: https://github.com//issues/4796
<dael> AmeliaBR: fantasai comment is resolution from a couple months ago was illogical so we should take it from there
<dael> fantasai: We rescinded the resolution in the same session b/c we had it could be 0.5 em or a glyph but fonts are neither so makes no sense. I think we start at the top.
<dael> Rossen_: What's the proposal?
<Rossen_> q
<dael> florian: It's okay if the first available font does not contain all glyphs. I think ch unit uses 0 glyph, ic uses a particular character. If the glyphs are missing the units can say I default to 1em or whatever. But we should still figure out what the first available font is
<dael> AmeliaBR: So one prop is the first font in the font stack with any valid glyphs is your first available font?
<dael> myles: That's what we do in WK. THe first font is the primary font and if it doesn't support the characters we'll use another one
<dael> florian: Problem in the spec is it says first font if it doesn't cotnain space it doesn't count
<dael> florian: One reason is common to put first font and reduce it via the unicode range. You're just using that font for & or something and want rest of the stack for the rest.
<dael> florian: As jfkthame pointed out it's if the font contains. If the change to if the unicode range it's webcompat
<dael> dbaron: Suggestion in issue is change it to be if unicode range matches the space and than it was added what to fallback to if there's not a glyph
<dael> fantasai: sounds like it's what we did before is for the value of ch and than ammend algo for first available font to see if space is in its unicode range
<dael> florian: And for ch unit it already says that. It says in [reads] (it's 0.5em wide)
<dael> florian: Could be interpreted as if not in first available font
<fantasai> https://www.w3.org/TR/css-values-3/#ch
<fantasai> "In the cases where it is impossible or impractical to determine the measure of the “0” glyph, it must be assumed to be 0.5em wide by 1em tall."
<dael> AmeliaBR: Can someone type up a resolution text for the proposal?
<fantasai> "Equal to the used advance measure of the "0" (ZERO, U+0030) glyph found in the font used to render it."
<dael> dbaron: I don't quite understand what happened last time, though we did retract original resolution in that discussion
<dael> florian: b/c made no sense. We said font becomes 0.5em which makes no sense.
<myles> Proposed Resolution: The first available font is the first font in the font-family list whose unicode-range supports the space glyph
<dael> fantasai: I put in text from Values. It says ch is the advance measure of the 0 in font used to render it. WHich is not same as first available. So that's separate. Need to resolve what first available font is. If there's an issue with ch it's separate.
<dbaron> I think a more specific proposed resolution is to accept jfkthame's proposal at the end of https://github.com//issues/4796#issue-568427691
<dael> fantasai: We should take prop from myles and if there's an issue for def of ch that's sep against values and units
<dael> AmeliaBR: On prop resolution do we have concept in spec what unicode means for system and generic
<dael> myles: Assumed to have definite range of every unicode character. Spec lists it out.
<AmeliaBR> s/unicode/unicode-range/
<dael> florian: Another clarification. If the first font in stack doesn't have space we skip it. If it does do we look if it has the glyph?
<dael> myles: We do not
<dael> Rossen_: Thoughts or objections to "The first available font is the first font in the font-family list whose unicode-range supports the space glyph"
<AmeliaBR> s/unicode-range character/unicode character/
<fantasai> s/supports/includes/
<AmeliaBR> s/what unicode means/what unicode-range means/
<dael> dbaron: There was working in issue
<dael> jfkthame: Should be talking about character not range
<dael> RESOLVED: The first available font is the first font in the font-family list whose unicode includes the space glyph
<fantasai> s/glyph/character/
<fantasai> s/unicode/unicode-range/
<dbaron> s/working/wording/
<AmeliaBR> s/first font/first available/