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