[css-fonts] Do generic fonts resolve to a single font face value?

[gsnedders]

See https://drafts.csswg.org/css-fonts-4/#generic-font-families and https://drafts.csswg.org/css-fonts-4/#font-matching-algorithm

Are:

• <p style='font-face: serif' lang='en'>Lorem ipsum dolor sit amet</p>
• <p style='font-face: serif' lang='jp'>Lorem ipsum dolor sit amet</p>

Guaranteed to render the same? The spec seems to imply, without directly stating, in various places that the generic font is a specific, probably user-specifiable font-face, which implies that they should. This is, I believe, not true in any browser: a Latin font is selected for the former, a Japanese font for the latter.

(Ref web-platform-tests/wpt#6926 which made me realise this is unspecified behaviour.)

[kahsieh]

Should the selection of a generic font not depend on language? It seems like there could be glyph availability issues.

[gsnedders]

Oh, actually this is totally bogus, because the font matching algorithm explicitly allows this. That said, I think we should tidy up some of the definition of generics to make that clear.

[gsnedders]

@kahsieh it seems like theoretically you could behave identically to font-family: Times New Roman where you ultimately end up in "If there are no more font families to be evaluated and no matching face has been found, then the user agent performs a installed font fallback procedure to find the best match for the character to be rendered. The result of this procedure can vary across user agents."

But yes, see previous comment.

[gsnedders]

So, things that to me imply a single font:

All five generic font families are defined to exist in all CSS implementations (they need not necessarily map to five distinct actual fonts). User agents should provide reasonable default choices for the generic font families, which express the characteristics of each family as well as possible within the limits allowed by the underlying technology. User agents are encouraged to allow users to select alternative choices for the generic fonts.

This is somewhat ambiguous, but without first reading the font matching algorithm closely I'd understand this to mean that they map to five actual fonts (see especially the parenthetical!). I'd probably right here introducing generics that user agents don't need to map to five fonts, and each can map to more than one based on element language and/or unicode range.

Any font that is so described may be used to represent the generic serif family.

(And similar statements for other generics.) This to me implies that a font is used to represent the generic font family, because I'd view representation as an exclusive act in this context.

[tabatkins]

I read the parenthetical to say the exact opposite - they don't necessary map to five distinct actual fonts (because they might map to a collection of fonts).

[AmeliaBR]

Rather than thinking of the generics as equivalent to a system font-family name, it is probably better to consider them as equivalent to an @font-face family, where a given family name can be derived from many different font files, each with different unicode ranges. Just with the added option of also dividing them by different language settings.

(Which maybe should be a font-face descriptor as well, kind of the opposite of font-language-override, to combine two different font files that you want the browser to treat as a single font, auto-switching by language variant. But that's a separate issue.)

But either way: if experienced web-spec-readers are getting confused and debating semantics, then the language could clearly use some clarification.

How about:

2.1.1. Generic font families

All five generic font families must always result in at least one matched font face, for all CSS implementations. However, the generics may be composite faces (with different typefaces based on the Unicode range of the character, or alternatively on the language of the containing element). They are also not guaranteed to always be different from each other.

User agents should provide reasonable default choices for the generic font families, which express the characteristics of each family as well as possible, within the limits allowed by the underlying technology. User agents are encouraged to allow users to select alternative choices for the generic fonts.

[kahsieh]

I'd agree with keeping language as a part of generic font selection and even adding it as a @font-face descriptor since CJK makes per-character codepoint-based selection difficult:

• CJK have partially intersecting character sets, so without taking language into account, we may get text made up of a variety of fonts even though it's all in the same language.
• Even if a single font contains faces for all the characters in some text, that font may not be for the correct language. (A single codepoint can map to different variant glyphs depending on the language, and this is reflected in fonts.)

For example, if we don't specify lang, the last character in this Japanese text is clearly rendered with a Chinese font in Chrome and Safari:

(and Firefox has the opposite problem).

[gsnedders]

@kahsieh Oh, don't get me wrong, I'm well aware this is totally relied upon, I guess I was just expecting something way more evil (like using Times New Roman or whatever for all non-CJK characters).

[kahsieh]

@gsnedders Of course! Just noting the use case should there be more interest in adding it to @font-face.

[AmeliaBR]

@kahsieh Since you seem to know more about the topic than I do, could you start the separate issue about lang as an @font-face descriptor? That way, we can keep that idea from getting lost, & discuss its details further, without distracting too much here.

[litherum]

@AmeliaBR's proposed text is the right direction, but we should go even further: a UA should be allowed to take any signals into account when selecting these fonts, including but not limited to lang, unicode-range, system language, user preferences, phase of the moon, etc.

This is a place where the UA should be able to just Do The Right Thing™.

[gsnedders]

@litherum then we need changes in the font matching algorithm too

[litherum]

@litherum then we need changes in the font matching algorithm too

Not if we're just discussing for mapping serif to another string. Or are we discussing something else?

[gsnedders]

@litherum See step 2:

If the family name is a generic family keyword, the user agent looks up the appropriate font family name to be used. User agents may choose the generic font family to use based on the language of the containing element or the Unicode range of the character.

I guess we can argue that doesn't need to change because as a "may" you are actually already allowed to do anything. That said, that's as much a requirement as @AmeliaBR's text above (similarly using "may").

[svgeesus]

How about this change to the first para from @AmeliaBR (I lke that text in general, but my rewording takes into account the comment from @litherum

All five generic font families must always result in at least one matched font face, for all CSS implementations. However, the generics may be composite faces (with different typefaces based on the Unicode range of the character, the language of the containing element, user preferences and system settings). They are also not guaranteed to always be different from each other.

Same language in fonts-4, except there are nine generics.

[svgeesus]

Did anyone like/dislike my proposed rewording?

[litherum]

I like it, but putting the list in normative text makes it seem like anything not in the list is disallowed. I think we should go with Chris’s text but either add a “etc. or “among others” or something like that. Alternatively we could pull out the parenthetical and put it in a note.

[AmeliaBR]

Looks good to me, with Myles' suggestion of making it clear that the parenthesis is a "for example" list, not a definitive one.

[dbaron]

So a few thoughts here:

• I'm generally a little hesitant to let something vary as a result of user preferences or system settings, but not as a result of user-agent implementor choices.
• However, it's not clear to me why that clause is needed: when would a user agent want to pick different fonts for the same Unicode codepoint in the same language with the same specified generic font? Reasons I can think of include: other codepoints in the same grapheme cluster, attempts to do language inference in various ways on text of officially unknown language, and possibly the font used for adjacent grapheme clusters (although I tend to think that's a bad idea). None of these are user preferences or system settings, though.
• If we do want to allow variation for these reasons, it seems likely that web content will come to depend on them (e.g., for correct rendering of CJK text), and we'll need to standardize them.

[css-meeting-bot]

The Working Group just discussed [css-fonts] Do generic fonts resolve to a single font face value?, and agreed to the following resolutions:

• RESOLVED: Take Chris's language in https://github.com/w3c/csswg-drafts/issues/1736 into the spec as an example

The full IRC log of that discussion

<dael> Topic: [css-fonts] Do generic fonts resolve to a single font face value?
<dael> github: https://github.com//issues/1736
<dael> Chris: Amelia suggested wording. I modified that based on myles' comments. Seemed generally liked, but myles wanted it not to be an exclusive list. Seems okay to me. dbaron commented recently.
<dael> dbaron: Yeah. I think if we're going to say it's okay to choose a different font for same unicode code point in same lang with same font we should have an idea of why we want to do that.
<dael> Chris: Yes.
<dael> dbaron: And user preference didn't seem to be a great desc of the reasons.
<dael> Chris: TO me it seemed more likely an impl may want to avoid ransom note effects or to avoid font family switches.
<dael> Chris: HOw should we proceed? Text I proposed has been there since Sept 2017. No one has said they didn't like. There were 2 lgtm from Amelia and Myles.
<dael> astearns: looks good comments only had the one cavet that they would like it to be "for example"
<dael> astearns: And dbaron are you okay with the existance of this as is or do you want more motivation?
<dael> dbaron: If it is flexible I'd rather it not be tied to that list so I guess for example is okay. That makes it more flexible. I don't have strong feelings here. I'm not crazy about flexibility but if is flexible for example is better.
<dael> Chris: And it's allowing generic to be made from composites .
<dael> dbaron: But that would be allowed without the varients in there. THat's the result of code point.
<dael> Chris: I think taking it back to initial comment that does resolve that Latin and Japanese aren't expected to be the same.
<dael> Chris: I propose that I put the modified language in the spec and we see if there's anything left ot do.
<dael> astearns: sgtm. Obj to putting this parenthetical as a for example into the spec?
<dael> RESOLVED: Take Chris's language in https://github.com//issues/1736 into the spec as an example

[svgeesus]

@gsnedders Checking you are happy with the eventual resolution