- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Sat, 03 Dec 2022 15:17:26 +0000
- To: public-css-archive@w3.org
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] Confirmation/clarification re parsing the @font-face src: descriptor == The CSS Fonts section on [Parsing the 'src' descriptor](https://drafts.csswg.org/css-fonts/#font-face-src-parsing) says that, having parsed the comma-separated list of component values: > If a component value is parsed correctly and is of a [font format](https://drafts.csswg.org/css-fonts/#font-format-definitions) or [font tech](https://drafts.csswg.org/css-fonts/#font-tech-definitions) that the UA supports, add it to the list of supported sources. If parsing a component value results in a parsing error or its format or tech are unsupported, do not add it to the list of supported sources. > If there are no supported entries at the end of this process, the value for the [src](https://drafts.csswg.org/css-fonts/#descdef-font-face-src) descriptor is a parse error. As I understand this, the intention is that if any individual component of the comma-separated `src` list cannot be parsed, that component (only) is to be omitted from the list of sources, but this does *not* cause the `src` descriptor as a whole to be rejected. This behavior is important for future extensibility: e.g. if a future version of CSS adds new font format or technology keywords, those will not be recognized as valid arguments to the `format()` and `tech()` functions by existing UAs. Therefore, a `src` component that specifies such a format or technology would give a parsing error in older UAs. The component should then be ignored as unsupported, but we do *not* want this to cause the entire `src` descriptor to be dropped. It appears that current browsers do not implement this behavior correctly; if they encounter a parse error in a component of the list, they treat the entire `src` descriptor as invalid. At https://codepen.io/jfkthame/pen/jOKedQm I've put a bunch of examples of `@font-face` rules with bad components in the `src` list. If my understanding of the spec (and the desirable behavior) is correct, all the test lines there should render with the same font as the reference line; but both Firefox and Chrome currently fail all the test lines, and Safari fails all but two of them (it seems to ignore invalid keywords in the `format()` function). I'm intending to fix this behavior in Gecko, unless people fundamentally disagree with my reading of the spec here. I also wonder if the spec should include an explicit example showing an invalid component in the `src` list and clarifying that other valid components are still to be used. cc: @drott @litherum @svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8183 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 3 December 2022 15:17:28 UTC