[css-fonts] Confirmation/clarification re parsing the @font-face src: descriptor
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 24
Description
The CSS Fonts section on Parsing the 'src' descriptor says that, having parsed the comma-separated list of component values:
If a component value is parsed correctly and is of a font format or font tech 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 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the CSS Fonts section on “Parsing the 'src' descriptor” and compare its wording with the examples in the linked CodePen. Determine whether the issue’s interpretation is accepted, then clarify the specification and add an explicit invalid-component example if that is the agreed outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- documentation, web-dev
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100