W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2017

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

From: Simon Sapin via GitHub <sysbot+gh@w3.org>
Date: Tue, 28 Mar 2017 09:56:07 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-289721210-1490694966-sysbot+gh@w3.org>
 >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.

> 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. 

>  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.

> 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 <selector-list>. 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.

GitHub Notification of comment by SimonSapin
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1133#issuecomment-289721210 using your GitHub account
Received on Tuesday, 28 March 2017 09:56:13 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:09 UTC