[csswg-drafts] [css-fonts] Clarify parsing of `<font-face-name>` for the `src: local(...)` function (#8187)

jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts] Clarify parsing of `<font-face-name>` for the `src: local(...)` function ==
The [`src` descriptor](https://drafts.csswg.org/css-fonts/#font-face-src-parsing) 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>`](https://drafts.csswg.org/css-fonts-3/#font-face-name-value) 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](https://www.w3.org/TR/css3-syntax/#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](https://drafts.csswg.org/css-fonts/#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](https://drafts.csswg.org/css-fonts/#propdef-font-family) keyword value (e.g. [CSS-wide keywords](https://drafts.csswg.org/css-values-4/#css-wide-keywords) such as [inherit](https://drafts.csswg.org/css-cascade-5/#valdef-all-inherit), or [<generic-family>](https://drafts.csswg.org/css-fonts/#generic-family-value) keywords such as [serif](https://drafts.csswg.org/css-fonts/#valdef-font-family-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_.

cc @svgeesus @drott @litherum 


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8187 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 5 December 2022 19:09:36 UTC