[css-fonts] @font-face src: url() format() keywords vs. strings ambiguous in spec

[drott]

Context: On the background of our plans to introduce COLR v1 color fonts we have requests from partner for feature detection for font formats.

One obstacle to reliable feature detection is inconsistent support for format() specifiers in engines, but even the spec is ambiguous on the syntax of the format specifier of the @font-face at-rule's src: line:

<url> [ format(<font-format> [supports <font-technology>#]?)]? | local(<font-face-name>)
<font-format> = [<string> | woff | truetype | opentype | woff2 | embedded-opentype | collection | svg]

Here, the font-format production allows a string and keywords.

Why does it allow a string, but parsing and meaning of that string is mostly left unspecified as far as I can see?

Engine behaviour

Engine behaviour is currently also inconsistent:

FF only accepts strings for what's in the format() function, compare https://bugzilla.mozilla.org/show_bug.cgi?id=650372

WebKit accepts strings or keywords and outputs the parsed at-rule in keyword style when looking at the parsed style rules: using something like document.styleSheets[0].cssRules[0].cssText.

Blink also expects a string here and then consumes the string as a whole, internally compares it to a supported format list, compare code. The CSSOM output is also generated as strings, the supported format values are validated, otherwise the src: line gets dropped.

Inconsistent Examples

In addition, the current spec has examples (example 22, 23) with " quoted strings for format() as well as an example (example 24) that uses keywords.

Suggested Changes

I suggest

• to freeze in the <font-format> production to be equal to an explicitly listed limited set of fixed strings (perhaps those at the time of when this was changed to keywords?) and explain how these are supposed to be interpreted (i.e. parse them analogously to the non-string parts of the <font-format> production).
• to specify that for the parsed CSSOM cssText value of the parsed at-rule keyword representations should be returned.
• to harmonise the examples in the spec to use the keyword syntax, i.e. change example 22 and 23 to use keyword syntax.