[css-fonts] Handling of @font-face rule which lacks font-family or src descriptor

[upsuper]

The spec currently says:

@font-face rules require a font-family and src descriptor; if either of these are missing, the @font-face rule is invalid and must be ignored entirely.

It defines a @font-face rule to be invalid if either font-family or src descriptor is missing, but it is not clear what does "ignore entirely" mean here. It could mean:

• the rule should be rejected by the parser like a syntax error, or
• the rule should be parsed, but ignored for font matching.

Currently in all modern browsers, it is handled in the second approach (that is, invalid rules are NOT rejected by the parser), but the spec should really make it clear.

[SimonSapin]

it is not clear what does "ignore entirely" mean here. It could mean:

• the rule should be rejected by the parser like a syntax error, or
• the rule should be parsed, but ignored for font matching.

Pretty sure "invalid" things should be ignored, and "ignore" means the former.

https://www.w3.org/TR/CSS2/conform.html#ignore

Ignore
This term has two slightly different meanings in this specification. First, a CSS parser must follow certain rules when it discovers unknown or illegal syntax in a style sheet. The parser must then ignore certain parts of the style sheets. The exact rules for which parts must be ignored are described in these sections (Declarations and properties, Rules for handling parsing errors, Unsupported Values) or may be explained in the text where the term "ignore" appears. Second, a user agent may (and, in some cases must) disregard certain properties or values in the style sheet, even if the syntax is legal. For example, table-column elements cannot affect the font of the column, so the font properties must be ignored.

https://www.w3.org/TR/CSS21/syndata.html

This specification defines ignore to mean that the user agent parses the illegal part (in order to find its beginning and end), but otherwise acts as if it had not been there.

A user agent must ignore a declaration with an invalid property name or an invalid value. Every CSS property has its own syntactic and semantic restrictions on the values it accepts.

At-rules with unknown at-keywords. User agents must ignore an invalid at-keyword together with everything following it, up to the end of the block that contains the invalid at-keyword, or up to and including the next semicolon (;), or up to and including the next block ({...}), whichever comes first.

https://drafts.csswg.org/css-syntax/

After each construct (declaration, style rule, at-rule) is parsed, the user agent checks it against its expected grammar. If it does not match the grammar, it’s invalid, and gets ignored
by the UA, which treats it as if it wasn’t there at all.

If any style rule is invalid, or any at-rule is not recognized or is invalid according to its grammar or context, it’s a parse error. Discard that rule.

The prelude of the qualified rule is parsed as a . If this returns failure, the entire style rule is invalid.

---

So the issue here is that implementation seems to be disagree with this part of the spec:

if either of these are missing, the @font-face rule is invalid and must be ignored entirely.

If such rules are not discarded at parse time, they are not considered "invalid" as the term is defined in CSS specifications. Maybe that last bit of quoted spec should be changed to align with implementations.

[litherum]

Maybe that last bit of quoted spec should be changed to align with implementations.

👍

[fantasai]

This is a substantial change against a CR spec, so needs a WG resolution.

[litherum]

Adding to F2F agenda, so removing Agenda+

[css-meeting-bot]

The CSS Working Group just discussed font-face without src, and agreed to the following resolutions:

• RESOLVED: font face rules should be in the om, apply for font settings, but should not be used for font matching
• RESOLVED: font face rules should be in the om, but should not be used for font matching (correction of previous statement)

The full IRC log of that discussion

<fremy> Topic: font-face without src
<astearns> github: https://github.com//issues/1133
<fremy> Github: https://github.com//issues/1133
<fremy> myles_: for a long time, at font face without src is ignored
<fremy> myles_: which means it is a parse error and is not there anymore
<fremy> dbaron: i would argue ignored could mean it's there in the om but then does nothing
<fremy> myles_: ok, I think it doesn't matter for what I want to think about
<fremy> myles_: in some cases, you can have font faces to alter font properties
<fremy> myles_: and all browsers accept to do that
<fremy> myles_: so I would like the text to be changed to say that the font face rule should not be used for font matching
<fremy> myles_: but should apply otherwise
<fremy> dbaron: i think that is the sensible way to "ignore" them
<fremy> TabAtkins: I have a follow-up question about whether we should apply a similar reasoning to invalid counter styles
<fremy> dbaron: it would make sense to me
<fremy> myles_: I cannot say that this matches browsers in that case, i have not tested
<fremy> TabAtkins: sounds good, but we could decide on a principle and update if needed
<fremy> Alan: what is the proposition then?
<fremy> myles_: (repeats previous proposal)
<fremy> RESOLVED: font face rules should be in the om, apply for font settings, but should not be used for font matching
<fremy> RESOLVED: font face rules should be in the om, but should not be used for font matching (correction of previous statement)
<astearns> s/, apply for font settings//