- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Mon, 31 May 2021 13:53:23 +0000
- To: public-css-archive@w3.org
drott has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] @font-face src: url() format() keywords vs. strings ambiguous in spec == 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](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/parser/at_rule_descriptor_parser.cc;l=95;drc=1107751b6f11c35259a1c5c8a0f716e227b7e3b4;bpv=1;bpt=1). 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 <string> 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. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6328 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 31 May 2021 13:53:33 UTC