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

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

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Mon, 09 Dec 2019 04:32:15 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-563058326-1575865934-sysbot+gh@w3.org>
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 name 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.

GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4566#issuecomment-563058326 using your GitHub account
Received on Monday, 9 December 2019 04:32:17 UTC

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