[css-fonts] Should all new generic family names win over @font-face names?

[kojiishi]

According to:
https://drafts.csswg.org/css-fonts-4/#family-name-syntax
The unquoted generic font-family names should not match @font-face nor existing font names.

As we add more generic families, and we changed the definition not to require to resolve to existing fonts, I wonder we may want to revisit this criteria too.

As the number of generic family increases, we'll increase the risk of snippets like this to behave differently by browsers:

@font-face { family-name: fangsong; ... }
html { font-family: fangsong; }

then browsers that supports fangsong generic family will ignore this @font-face.

In Blink, we apply this rule to system-ui, but haven't done so to other generic families yet.

[svgeesus]

A similar issue in CSS Color was dealt with by making the author-supplied identifiers be dashed idents. I don't thinks we can do that here though, because the weight of existing usage is too great. So yes, if we constantly make new generics then there is a risk that they clash with previously-ok user supplied names. The only wiggle room we have is the use of quoting:

@font-face { font-family: "serif"; ...}
html { font-family: "serif", serif }

This will use the webfont called "serif" and then as fallback the generic font family serif.

[Crissov]

CSS should have deprecated unquoted custom font families (in properties and descriptors) long ago. It should then have introduced keywords for popular typefaces: arial, helvetica, times etc. That does not work for multi-word names like Times New Roman, but fortunately those are more often used with quote marks.

#4910

LeaVerou/css-almanac#15 -> HTTPArchive/almanac.httparchive.org#902 (comment)