[css-fonts] Should we start a registry for additional generic fonts?

[frivoal]

(forked from #4397 (comment), relates to #4397 and #4425)

Given the conclusion of #4442, the generic font families aren't actually special in terms of behavior with regards to how they match (or not) and how they fallback. They are just commonly accepted names for generic concepts, and nothing bad or unusual happens if a browser fails to support some of them (since authors can just supply fallbacks, whether other generic families, or named local fonts, or web fonts).

Given that, I think we should start a separate document, outside of css-fonts, maintained as a registry rather than as a spec, where we list a larger set of generic font families than had been accepted so far, without requiring browsers to implement the whole set. I'd expect aditions to the list to be mainly diven by i18n needs, and it could list things like fangsong, nastaliq, Ruq'a, or Mool, but could also have things like humanist or fraktur, or system-ui-*, or be a honorable retirement place for fantasy. I don't suggest listing everything we can think of there, as there would be no end to that list, but we could list any generic name actually implemented by a User Agents.

This would:

• allow UAs to support new generic family names for which they see meaningful demand (without being accused of making proprietary extensions)
• let UAs that don't agree on the need for that family to keep ignoring it (without being accused of violating the spec)
• help UAs to coordinate with each-other on the naming and meaning of new values when they do agree there's a need
• give authors a centralized place to discover these values and their meanings.
• Let the spec focus on the mechanics of how fonts are handled and do it's CR/REC transitions when appropriate for that, while letting the listing of fonts live it's life separately, without tying the release cycle of one to the other.

---

Process wise, we're trying to introduce a new type of document that would be appropriate for this in Process 2020 (Registries), but until we get there, this could be a Note.

[fantasai]

I understand you might be excited about a new type of W3C specification :P but I think definitions here should be ones we all agree on and which are implemented interoperably, not things that are registered by a UA acting on its own and are excluded from W3C RF patent obligations.

For a given OS, whether or not system-ui or system-sans-serif exists and what font it corresponds to is an answerable question, and it should be answered the same for all UAs on that OS.

Similarly, we are requiring that if a sans-serif font or serif font exists on the system, one must be mapped to that keyword.

If you want to argue that we should extract the list of font keywords into its own spec, I might entertain that notion. But I'm not convinced that it should be a registry rather than a REC-track standard. Registries are for things like mappings, not for normative definitions of things.

[litherum]

I agree with @fantasai. I don't see any reason to deviate from the existing process regarding these generic font families. I believe the current system solves all the desires listed in the bullets of #4566 (comment).

[frivoal]

To me, the interest in the registry is more for things like fangsong and possibly nastaliq than for serif or ui-serif (which do have some degree of must associated with them): there's a good chance that we'll need more of them to support the needs of i18n, and they'd typically be described without any must or should beyond what the property definition already says: "The blah family corresponds to the ??? typographic tradition of the ??? writing system". Also, given that there's a very graceful fallback, I'm not sure I'd require/expect every UA to support all of them. I wouldn't want to block fonts-4 from REC because of an insufficient number of implementations of (for example) nastaliq. Or, less theoretically, of fangsong. Even if we did, for any given such font, there isn't really an observable difference between supporting it but not having a relevant font at hand vs not supporting it.

Once the mechanics of the font-family property are established in the REC track spec, the actual long tail of generic family names feels more like a list of well known names than like normative spec text.

If the list probably won't change and will stay as it is now, no need for anything new. I suspect it will grow (given that it already has started growing, and there we have requests for more), and so a separate document probably does make sense to avoid tight coupling between the release cycle of the mechanics parts and the font-list parts of css-fonts-4.

Now, if we all agree that the minimum requirement for being in that list would be two or more implementations, we can keep it on the REC track. But I suspect the bar could be a bit lower than that, and that with even with a single vendor interested in a value, ensuring non collision and non duplication, as well as giving the css-wg and i18n an opportunity for feedback could be enough for our purpose, even though it wouldn't be for REC.

[c933103]

Wait a moment, according to my limited understanding fangsong and nastaliq seems to be something totally different from other proposed font families?
For things like Nastaliq for arabic script, Fraktur for latin script, Small seal script for han script, they all seems to be different writing system variants of the same family. It will probably be better to handle them with the help of ISO 15924 where some of them are either already registered or will probably be eligible to register in there.
On the other hand, for things like Fangsong for Chinese, Kaiti for Chinese, or Marugothic for Japanese, they will probably be more appropriate for font family registry.

[davelab6]

They are the same writing system. Same unicodes.

[svgeesus]

Related: Font styles & font fallback