[css-fonts] Clarify parsing of <font-face-name> for the src: local(...) function #8187
Description
The src descriptor of an @font-face rule has a comma-separated list of component values.
One type of component value is a local font specified using the local() function. The <font-face-name> argument to local() is:
a unique font face name enclosed by "local(" and ")". The name can optionally be enclosed in quotes. If unquoted, the unquoted font family name processing conventions apply; the name must be a sequence of identifiers separated by whitespace which is converted to a string by joining the identifiers together separated by a single space.
Here, I presume "the unquoted font family name processing conventions" must be referring -- although not linked in the spec -- to the more detailed description of the <family-name> syntax found in the context of the font-family property.
The "unquoted font family name processing conventions" mentioned in the <font-face-name> description clearly refer to the construction of a single string name from a sequence of space-separated identifiers, as for example local(Times New Roman Bold), to identify the same face as local("Times New Roman Bold").
What's less clear to me is whether these "processing conventions" also encompass the restriction that:
Font family names that happen to be the same as a font-family keyword value (e.g. CSS-wide keywords such as inherit, or keywords such as serif) must be quoted to prevent confusion with the keywords of the same names.
In the context of the <font-face-name> argument to local() in an @font-face rule, it would not be meaningful to use a CSS generic-family (because the argument is not a font family at all, it's an individual font face), and so arguably there is no risk of confusion; a component like local(serif) must unambiguously refer to a font face whose actual name is "serif", and not to the (potentially composite and/or language-dependent) font family to which the property font-family: serif would refer.
Still, I think it is unhelpful to permit unquoted generic-family identifiers here; users have enough difficulty with the family/face distinction already. And perhaps the mention of the "family name processing conventions" should be taken to include the rule excluding such keywords.
So in short, my question -- which I do not think the spec clearly addresses -- can be boiled down to whether the rule:
@font-face { font-family: foo; src: local("serif"); }
can equivalently (although confusingly) be written as:
@font-face { font-family: foo; src: local(serif); }
or is the latter a parse error, resulting in a rule that lacks any valid source?
Currently, it appears that WebKit and Blink both accept the unquoted generic-family here, while Gecko does not. However, I would suggest that Gecko's behavior is preferable, and should be explicitly spec'd. In the (unlikely) event that a user really does want to refer to a local font face literally named "serif" (for example), they can do this using a quoted string. Accepting the unquoted identifier misleads users into conflating font faces and font families.