[css-fonts] Don't require browsers to always match every generic font family to a concrete font family

[litherum]

CSS Fonts currently says:

Each generic font family must always map to at least one matched font face.

I'd like to propose deleting this sentence because it does not accomplish its goal, nor could it ever accomplish its goal. This is because browsers are free to map the generic font families to any concrete font or font stack, regardless of that font's Unicode coverage. There's no guarantee that, when an author specifies a generic font family, that the concrete font can actually be used for any of the content on the page. Indeed, the mapped font could be a font which supports 0 characters.

I'd also like to add a sentence encouraging authors to use generic font families in their font-family lists. This provides a signal for what kind of font the author desires, regardless of whether or not it actually ends up being used. WebKit (and other browsers too?) will consider this kind of signal when we "fall off the end" of the font-family list and have to pick a font for the content but can't use any of the fonts in the specified list.

I'm not actually proposing any behavior change in browsers. The difference between fantasy mapping to a font that supports 0 characters, and fantasy not mapping to any font, is untestable. Untestable things shouldn't be normative in specs. EDIT: This is false. See #4442 (comment)

This has implications for the new ui-serif, ui-monospaced, and ui-rounded font families. We resolved that these shouldn't map to any concrete fonts on platforms that don't have an appropriate UI font for them. Therefore, under the current text, they can't be generic font families, and should instead be a new class of fonts. I don't think it's valuable to have two distinct classes of fonts in the spec when their difference is meaningless and untestable.

[kojiishi]

+1

This provides a signal for what kind of font the author desires, regardless of whether or not it actually ends up being used. WebKit (and other browsers too?) will consider this kind of signal when we "fall off the end" of the font-family list and have to pick a font for the content but can't use any of the fonts in the specified list.

Yeah, Blink wishes to do this too.

[svgeesus]

I'm in favor of deleting that sentence.

I'm in favor of encouraging authors to use generics, and specifically motivating this (beyond general "it is good to do so") by saying this affects browser behavior when the end of the font stack is reached.

[tabatkins]

WebKit (and other browsers too?) will consider this kind of signal when we "fall off the end" of the font-family list and have to pick a font for the content but can't use any of the fonts in the specified list.

Can you elaborate on this? I don't understand what you mean - are you saying that if the author puts serif at the end of their stack, but they use a character not mapped by the font that WebKit assigns to serif, it'll still influence what additional fonts WebKit looks for to find a mapping for the character?

[frivoal]

It was my understanding that generic families always matched (even if they had not usefully distinct character to provide), and therefore that it made no sense to put any fallback after a generic font family, as it would never be reached. However, It doesn't seem to actually be true, and it seems that when a generic font family does not provide a glyph for a particular unicode code point, browsers do allow fallback to font families specified after it in font-family.

I can think of a few possible variants of what the "Each generic font family must always map to at least one matched font face." might mean:

1. It means nothing, generic families behave like any other font family: they may be composites of multiple actual font faces in order to cover a broad unicode range, and when they don't match for a given character, we fallback to whatever is next in the specified font stack, and eventually to the system fallback if nothing matches.
2. It means that generic font families include the "fall off the end" fallback, and always match. Due to limitations on what's available on the system, not all components of a generic family will be usefully differentiated to match the requested style, and multiple generic families may share some font faces in their stack, but regardless, they always match, even if it is just to show a tofu glyph. Listing a font (generic or not) after a generic one in font-family never has any effect.
3. Generic families, like any other family, may or may not have glyphs for the characters at hand, and when they don't, fonts listed after them are used as fallbacks. They may possibly contain no glyph at all, depending on what's available on the system, but even in that case, if no specified font family prior to in in the font stack has a glyph for U+0020, the (empty) generic family still counts as the "first available font", and this impacts things like the line-height or the size of the font relative units.

I think variant 3 is not useful, and we should not do that.

I (and at least some other people as well, given the recent discussions around this topic) thought that variant 2 was the specified (and implemented behavior). It does not seem to be the implemented behavior. As far as specs go, they all seem somewhat ambiguous, and the wording has evolved between css2, fonts-3, and fonts-4. The older wordings (see css2 for example) seem to me to be more strongly calling for behavior 2 than the newer ones, but none of them is 100% clear cut.

Variant 1 is explicitly the one we said we wanted for system-ui and the like. For other generic families, it seems to be what browsers actually implement, and may be a good idea: I always assumed that writing @font-face { font-family: "micho fallback"; src: …; } html {font-family: serif, "mincho fallback"; } was not a thing I could do in order to supply a web-font based fallback for systems that didn't have a Mincho font, while leaving those that do use the system font. But it seems it's actually possible, and it is very useful, so I support behavior 1 for all generic font families.

Picking behavior 1 also makes questions like the one I raised in #4425 largely go away, as behavior 2 was the assumption underlying that question.

are you saying that if the author puts serif at the end of their stack, but they use a character not mapped by the font that WebKit assigns to serif, it'll still influence what additional fonts WebKit looks for to find a mapping for the character?

That question only makes sense if we go for behavior 1 (or 3), because with behavior 2, the fallback is part of the generic font family itself, not something that happens after it.

If we do go with behavior 1, in order to set author's expectations it would be useful to specify whether:

• the fallback must be independent of the specified font stack
• the fallback may be influenced by the last font in the specified font stack if it is generic
• the fallback may be influenced by the last generic font in the specified font stack, even if it is followed by non generics
• the fallback may be influenced by [... some other specific thing ...]
• the fallback may be influenced by the specified font stack in arbitrary ways up to the UA

[kojiishi]

WebKit (and other browsers too?) will consider this kind of signal when we "fall off the end" of the font-family list and have to pick a font for the content but can't use any of the fonts in the specified list.

Can you elaborate on this? I don't understand what you mean - are you saying that if the author puts serif at the end of their stack, but they use a character not mapped by the font that WebKit assigns to serif, it'll still influence what additional fonts WebKit looks for to find a mapping for the character?

Our impl is very similar to what @litherum explained; generic families (except system-ui) are mapped to single font, so it is not guaranteed to match. We even allow users to change the mapping.

Regardless generic families are used or not, we have a logic to run when all specified families are exhausted and still the glyph is missing. This logic doesn't have a good name, I think this is what @litherum called "fall off the end". I usually call it "system fallback" but this isn't probably a common name, I think you called it "last resort font" (in broad sense, not the "LastResort" font unicode.org provides), this is probably more common.

A discussion we had before was that, during this "fall off the end or system fallback or last resort font in broad sense" process, we may find multiple candidates, and the idea was that generic families in the font-family property can provide a hint to which candidates we want to choose. font-weight or font-style can also provide more hints.

Back to the original discussion, I don't have strong opinion on whether the spec should encourage authors to use generic families or not, I'm fine with it or without it, but I agree with @litherum that more hints from authors could improve our font choice.

[kojiishi]

/cc @drott

[litherum]

@tabatkins

are you saying that if the author puts serif at the end of their stack, but they use a character not mapped by the font that WebKit assigns to serif, it'll still influence what additional fonts WebKit looks for to find a mapping for the character?

Yes, in some situations.

[litherum]

@frivoal What's the difference between option 1 and 3? They sound the same to me.

[frivoal]

Let's say your font stack is: p {font-family: fantasy, Helvetica; } on a system which has chosen not to map fantasy to anything (or equivalently, to a conceptual font with no glyphs in it).
You try to display <p>hello world</p> with it. If you don't like the idea of mapping fantasy to nothing, replace with fangsong with no loss of generality.

If we've ruled out option 2 (which disallows falling back from a generic family and requires that it maps to something for all glyphs), the logical thing (option 1) to do is to say that since fantasy doesn't match, then not only is helvetica (assuming it's actually available) the font that's actually used to render the text, but also since fantasy has no glyphs, Helvetica is also the first available font, and therefore its metrics are used to determine the line-height, ch unit, ex unit, etc. I support this.

"option 3" proposes one possible way to interpret the sentence that you propose to delete (about generic families always having to match), which would be to say that fantasy is in this case the first available font, and that the various measurments discussed above are based on it. That doesn't really say what they'd be, given that it's a conceptual font with no glyphs (and no obvious metrics) in it, but at least it wouldn't be based on helvetica. I think this is far fetched and undesirable, but if that sentence is there and means something I can't think of anything else than "option 2" or this "option 3".

Option 1 seems useful. Option 2 less so, but still sane. Option 3 seems just bad/silly to me. If anyone has a different understanding of what that sentence means, it'd be good to hear it before we remove it.

[litherum]

Oh, I think I understand. You're proving that my statement:

The difference between fantasy mapping to a font that supports 0 characters, and fantasy not mapping to any font, is untestable.

is false.

I believe you are correct, and my statement is false. Even if fantasy supports 0 characters, its presence is still observable, because it still will have metrics and therefore affect line height. Cool.

[litherum]

I'd like to propose option 1.

[tabatkins]

Agree, option 1 seems best all around.

Looping back to @frivoal's earlier question:

If we do go with behavior 1, in order to set author's expectations it would be useful to specify whether:

• the fallback must be independent of the specified font stack
• the fallback may be influenced by the last font in the specified font stack if it is generic
• the fallback may be influenced by the last generic font in the specified font stack, even if it is followed by non generics
• the fallback may be influenced by [... some other specific thing ...]
• the fallback may be influenced by the specified font stack in arbitrary ways up to the UA

Any opinions? @koji seems to be suggesting it's the last one (influenced in arbitrary UA-specific ways) in Chrome.