W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2019

[csswg-drafts] [css-fonts] Should we start a registry for additional generic fonts? (#4566)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Fri, 06 Dec 2019 00:54:04 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-533682607-1575593643-sysbot+gh@w3.org>
frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts] Should we start a registry for additional generic fonts? ==
(forked from https://github.com/w3c/csswg-drafts/issues/4397#issuecomment-547350192, relates to https://github.com/w3c/csswg-drafts/issues/4397 and https://github.com/w3c/csswg-drafts/issues/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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4566 using your GitHub account
Received on Friday, 6 December 2019 00:54:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:57 UTC