[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.

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts-5] How to add new generic font families, and agreed to the following:

• ACTION i18n: Propose script-specific generics
• RESOLVED: Add a generic() function, for generic font famlies that are not defined across all of unicode

The full IRC log of that discussion

<TabAtkins> addison: Another checkin, we've been discussing potentially more generics to support writing/typography traditions in other parts of the world
<TabAtkins> addison: Beyond the existing standard set, to let people use named generics rather than requriing authors to hunt for specific font names
<TabAtkins> addison: We've discussed this in our meetings
<TabAtkins> florian: Status update is same as last time
<TabAtkins> florian: Status: complicated
<TabAtkins> addison: So partly the status is, mutually trying to gather examples of generic styles that can't just be mentally mapped to the existing generics, where not having the distinction would impair the reading of the doc.
<florian> q+
<TabAtkins> addison: r12a compiled a doc of langs with stylistic differences that don't fall into the existing buckets
<wolfgang> s/requriing/requiring/
<xfq> https://www.w3.org/International/articles/typography/fontstyles.en
<TabAtkins> addison: Where maybe having named generic would be useful for authors to say what they want and get the desired behavior.
<TabAtkins> addison: Challenge is that since they're usually narrowly script-specific, what happens for `nastaliq` in Chinese?
<drott> q+
<TabAtkins> addison: And also how would CSS encode additional generics, without exploding the set.
<astearns> ack florian
<TabAtkins> florian: One challenge was, for these things that are only relevant to a subset of unicode, what does it mean for the rest.
<TabAtkins> florian: The other is i18n have compiled a list of groupings, but within this there's a gradient of "essential" to "common but authors would survive without it" and everything between.
<addison> q?
<addison> q+
<chris> q+
<TabAtkins> florian: So it's a question where the CSSWG wants to place the bar, doing the research to show the distinction is important enouh requires research
<TabAtkins> florian: Looking thru books/etc to see that it's a style you need that would not just be visually jarring without, but actually be misunderstood
<wolfgang> s/enouh/enough/
<TabAtkins> florian: I think elika had a criteria that if we find fonts in the first group it's undeniable we need them, because it causes misunderstandings
<chris> qq+ to point to an existing resolution re "the rest"
<TabAtkins> florian: But that research is hard. Should probably only be done if we want to be that strict.
<myles> q+
<TabAtkins> florian: If we're okay with less strict criteria - visually jarring, even if not causing misunderstanding - finding fonts over that bar is much easier
<TabAtkins> florian: So where CSS wants the bar will affect how we'll do research
<astearns> ack chris
<Zakim> chris, you wanted to react to florian to point to an existing resolution re "the rest"
<chris> https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-561913410
<TabAtkins> chris: We ahve an existing resolution on what to do if they don't apply to the script
<TabAtkins> chris: It's in the spec, they just don't do anything
<astearns> ack drott
<chris> q?
<TabAtkins> drott: I think florian's comment was good, about criteria
<chris> q- chris
<myles> q- i think chris said what i was going to say
<myles> q-
<TabAtkins> drott: I brought up some ipml questions about what to apply
<wolfgang> s/ahve/have/
<TabAtkins> drott: For existing generics we usually have UIs and user prefs to apply them.
<TabAtkins> drott: If we add a bunch, we'd have to expand that UI, and that could confuse users.
<TabAtkins> drott: If we don't add UI, can we agree on the criteria?
<TabAtkins> drott: Finding good fonts that recognize the distinctions...
<TabAtkins> drott: We have trouble finding them consistently
<astearns> q?
<TabAtkins> drott: So what are good candidates? Can we agree on how fonts map to the keywords?
<TabAtkins> florian: I wonder, if for those values, we can start a registry of known fonts that map to the style
<addison> q-
<TabAtkins> florian: I don't think blessing some fonts in the spec is fair to font vendors
<TabAtkins> florian: But a list of "all these fonts are known to be okay for nastaliq" is okay, UAs can draw from this when picking up from the OS
<TabAtkins> drott: If the OS doesn't have it, what do we do?
<TabAtkins> florian: fallback
<dbaron> Maybe such a list could be in a more editable document that's linked from the spec?
<TabAtkins> astearns: That's relevant to the previous issue, you have to define a fallback for anything we add
<myles> q+ to ask if there is a specific proposal
<TabAtkins> astearns: So we're stuck on finding a criteria.
<fantasai> dbaron, https://www.w3.org/2023/Process-20230612/#registries
<TabAtkins> astearns: Probably not a good idea to take the most important one and derive a criteria from that?
<TabAtkins> florian: i18n has done research and found a bunch that are relevant
<chris> q+ to ask if we like the "generic prefix" proposal for new generics
<addison> q+ to ask if a new feature would be appropriate
<r12a> q+
<chris> q?
<emilio> florian: maybe we just take i18n's advice directly?
<emilio> myles: is there a specific proposal? Not quite sure what we're talking about
<TabAtkins> myles: The spec already has pictures of example fonts for many generic famlies
<TabAtkins> myles: I don't think we need another document listing more examples
<TabAtkins> myles: i think the pictures in the spec are good enough
<wolfgang> s/famlies/families/
<TabAtkins> florian: Maybe we just take i18n's advice directly and start from their recs
<TabAtkins> myles: Is there a specific proposal?
<TabAtkins> chris: So there's 3 ways to go.
<TabAtkins> chris: One is we add a small, select number of generics.
<astearns> ack myles
<Zakim> myles, you wanted to ask if there is a specific proposal
<astearns> ack chris
<Zakim> chris, you wanted to ask if we like the "generic prefix" proposal for new generics
<TabAtkins> chris: Two is there's a bunch, possibly hundreds. As soon we find a distinction in a writing system, we add them.
<astearns> q++ chris
<astearns> ack +
<TabAtkins> chris: Three is generics are bad, we add these three and then never again.
<TabAtkins> myles: iirc there's a GH issue, and it resolved that 1 and 3 are bad, so that leaves 2.
<TabAtkins> myles: We've already solved "what does nastaliq mean in Chinese?'
<TabAtkins> myles: If i18n says a bunch of families are useful, let's do it
<astearns> ack chris
<TabAtkins> chris: so there was a proposal that if we add new generics we add a prefix or something
<TabAtkins> chris: problem at the moment is they look like normal font names
<florian> q?
<florian> q+
<TabAtkins> chris: I think the grouping is ugly but more scalable.
<TabAtkins> chris: like `generic(nastaliq)`
<r12a> q-
<addison> q-
<TabAtkins> myles: Don't think I have an opinion, except that if we do have a grouping mechanism it should be a function rather than a prefix.
<TabAtkins> chris: So that's what I was on the q for, to ask if we want the generic syntax.
<astearns> ack fantasai
<Zakim> fantasai, you wanted to comment on complete generics vs incomplete generics
<TabAtkins> astearns: So should we resolve on adding new font families via generic syntax?
<TabAtkins> fantasai: I think we should add a new syntax, but only for incomplete generics.
<TabAtkins> fantasai: complete is one that applies to every writing system, it is an endpoint for fallback
<TabAtkins> fantasai: monospace, serif, sans-serif are those
<TabAtkins> chris: There's not just examples, they're the only ones
<TabAtkins> fantasai: No we have system-ui, etc
<TabAtkins> chris: No we have a resolution that *those three* always match, the others might fail
<TabAtkins> chris: So the "complete" distinction already exists
<TabAtkins> myles: Two very similar things
<TabAtkins> florian: One is "things that always match across all of unicode, and will never fallback past"
<TabAtkins> florian: Then the UI ones which are defined across unicode but might not exist, they can fallback
<TabAtkins> chris: Yeah I think that's the distinction.
<TabAtkins> astearns: So back to generic functional syntax
<TabAtkins> myles: I think if we add a function, the dfn should not be "every generic font family after Sep 14 2023"
<TabAtkins> myles: I think it should be somethin like what elika gave, based off the meaning
<fantasai> +1 Chris, that's exactly what I meant
<TabAtkins> chris: What about names already defined that would fail the criteria?
<TabAtkins> myles: We'd keep them for compat but also allow them in generic()
<fantasai> (Chris suggested fangsong -> generic(fangsong))
<fantasai> myles++
<TabAtkins> myles: So the rule for what gets `generic(foo)` and which gets `foo` is based off of something meaningful, not just date added
<TabAtkins> fantasai: I think the distinction should be if the font is defined across all writing systems, or is specific to one writing system
<TabAtkins> myles: think that's reasoanble
<TabAtkins> proposed resolution: add `generic(...)` function, whose values will be the set of fonts that are generic but script-specific
<florian> +1
<fantasai> s/fonts/generic fonts/
<TabAtkins> chris: So that means ui-rounded doesn't get it, it applies across all of Unicode
<TabAtkins> myles: Don't have an opinion, sounds fine
<TabAtkins> fantasai: of the existing generics, only want would go into generic() is fangsong
<TabAtkins> astearns: Objections?
<chris> +1 to proposed
<TabAtkins> myles: And the reason we're doing this is so that i18n can add a bunch of generic families. Please give us that list
<fantasai> ACTION i18n: Propose script-specific generics
<TabAtkins> RESOLVED: Add a generic() function, for generic font famlies that are not defined across all of unicode
<TabAtkins> florian: Earlier Myles said 3 options, add a few, add a bunch, add nothing
<TabAtkins> myles: that was chris
<wolfgang> s/famlies/families/
<TabAtkins> florian: Ah, I think you said "add a few" and "add nothing" was bad was established
<TabAtkins> florian: I thought it wasn't established yet. Want to reconfirm that "add a bunch" is fine.
<astearns> +1 to a bunch
<TabAtkins> florian: So are we indeed in the situation that we're okay to add a bunch?
<TabAtkins> astearns: Any concerns about adding a bunch of script-specific generic font families?
<TabAtkins> myles: I think I wrote a set of criteria a few years ago
<TabAtkins> myles: There have to *be* at least two fonts that exist that can map to this keyword
<TabAtkins> myles: And generic families are only useful for installed fonts, so there has to be popular OSes with an example of that font.
<addison> q+
<TabAtkins> TabAtkins: I like those rules
<astearns> ack florian
<astearns> ack addison
<fantasai> fantasai: or installed with language packs
<TabAtkins> addison: Particularly for small lang communities, who often require installing their fonts, if people, to use their language, install some fonts, and use the necessary generics.
<TabAtkins> myles: If everyone is installing a particular font, then content can just name that font
<TabAtkins> <br type=lunch dur=60min>

[cdoublev]

Before the changes fixing this issue, <generic-family> was (and is still) defined as a keyword.

<generic-family>: Each <generic-family> keyword represents a generic font choice [...]

Now it is not clear:

<generic-family> = generic( <custom-ident>+ ) | <string> | <custom-ident>+

Is it intentional to allow <string> and one or more custom identifiers?

I would prefer to have generic font family names inlined in the value definition or abstracted with <generic-family-name> (for example) rather than <custom-ident>.

[xfq]

The title and label are both for L5, but the change was for L4. Should we change the title and label?

[svgeesus]

The new generic() functional notation is in Fonts 4. I would expect any new generics which use that syntax to be proposed in Fonts 5, as we are trying to stabilize Fonts 4 and get it to CR.