[css-fonts-5] How to add new generic font families

[svgeesus]

We agreed on the 27 Oct 2021 call to start a new issue about how to add generic font families. Below is my understanding of the current direction, as a way to start discussion.

There are two ways to go with the future evolution of generics:

1. Deprecate a couple, don't add any more, depend totally on downloaded webfonts
2. Realize that, as @r12a demonstrated, a large number need to be added, come up with criteria for adding them and a plan, perhaps a registry for trying out new ones, and recognize that these represent important distinctions which are necessary for some languages or scripts and may not be useful, or indeed map to an actual font, outside that usage.

It seems we have broad agreement that option 2 is the way to go.

This implies that new generics will be steadily added over time, which as @kojiishi noted gives us a potential name-clash problem. @frivoal suggested a generic() functional notation which would neatly solve that issue. @jfkthame had also suggested a functional notation

We should avoid being over-specific, as @fantasai mentioned, but also avoid being over-general or drawing forced analogies that do not take into account cultural factors (for example saying that cursive means brush drawn and also playful or informal, when it may mean the exact opposite, like "official and somewhat archaic government pronouncements"). And as @litherum noted, it is easier to discuss specific families rather than being too meta, once we have a general direction agreed upon.

In Scope

Finding the existing generic categories that particular communities need, and for each one document

• the name
• a description of what it signifies and how it is used
• at minimum ,one font which would be appropriate for that generic. More is better.
• the languages or scripts which are the primary audience for this generic.

Retrospectively applying that procedure to existing and already-proposed generics

Deprecating fantasy

Out of Scope

User-defined generics (how would content authors discover and use them)

Creating the latest and best completely universal type classification system which can accurately and uncontroversially classify any typeface ever created to an astonishing level of detail, which everyone agrees is the right one

(This spun out from [meta] [css-fonts] Criteria for generic font families #4910 )

[svgeesus]

We had already resolved

RESOLVED: serif, sanserif, and monospace must match, all other generics should match if appropriate.

[svgeesus]

A quick test indicates that

font-family:  generic(foobar), Garamond, serif;

causes the entire declaration to be discarded.

[xfq]

Finding the existing generic categories that particular communities need, and for each one document

• the name
• a description of what it signifies and how it is used
• at minimum ,one font which would be appropriate for that generic. More is better.
• the languages or scripts which are the primary audience for this generic.

We already have a lot of such information for some proposals, such as Kai. We need to decide whether we are maintaining it in css-fonts or in a separate document. And it would be useful if we have a submission process and maybe a template.

We also need to spec the functional notation (in css-fonts? or css-values?) if we have consensus.

[svgeesus]

Agreed; I was looking to get consensus on what common information is needed before harvesting proposals (many of which have already been made). As you say, a template would be a good idea.

[Crissov]

If a function like generic-font(), doesn’t work well there, how about a hyphenated prefix, either a single, general one like generic- or script-specific ones like latin- or euro-?

[jfkthame]

Hyphenated prefixes seem more problematic to me, because (especially if we may eventually have quite a lot of them) they potentially conflict with author-specified font family names. It's not too much of a stretch to imagine an author writing @font-face rules to define a family such as latin-cursive or euro-modern, etc., never expecting it to clash with built-in generics.

I'm not sure generic(....) is really a problem. If it causes old browsers to drop the entire declaration as invalid, authors should simply provide two font-family declarations: first, one for old browsers using only the existing syntax, and then override it with a new-syntax version for browsers that understand it.

[svgeesus]

If it causes old browsers to drop the entire declaration as invalid, authors should simply provide two font-family declarations: first, one for old browsers using only the existing syntax, and then override it with a new-syntax version for browsers that understand it.

That will work for new generics that are only available with the new syntax, but there is no incentive for content creators to use the new syntax for the existing generics. Which may be fine.

[litherum]

I don't think we should change the existing generics. If it ain't broke, don't fix it.

[svgeesus]

Probably wise, but what do we count as "existing". Are fangsong and math and emoji existing? I would argue not.

[litherum]

Sure, okay.