This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following stylesheet: @chars [.-;abc]; p {color: red} yields as effective result: p {color: red} This is wrong according to the specs, the effective style sheet should be empty. Reason: A stylesheet consists of rule-sets and at-rules. The above stylesheet partitioned according to the recognition rules for both of these looks like: ATRULE="@chars [.-;" The at-rule extends up to the first semicolon as there is no block. RULESET="abc];p {color:red}" This is because we parse until we find the end of the first block, and it cannot be an at-rule since it doesn't start with "@...". So the stylesheet consists of two rules, an ATRULE and a RULESET. Let's have a look at the rule-set: The selector is everything up to the first opening brace, so the selector is "abc];p " . This is a selector which cannot be parsed according to selector rules, hence it is invalid. If a selector is invalid, it and its corresponding declaration block must be discarded. Follows that the RULESET must be discarded. Since the ATRULE consists of an unknown ATKEYWORD, it is discarded. Likewise, due to its invalid selector, the RULESET is discarded, so effectively the resulting stylesheet is the empty stylesheet. That's however not what the validator delivers as result, so this must be considered a bug.
The intention of the generic grammar and the parsing rules is to allow additional @-rules in the future, should the need arise. Those @-rules must all be of the form ATKEYWORD S* any* [ block | ';' S* ] (1) However, "@chars [.-;abc];" *isn't* of that form. The non-terminal "any" cannot contain a semicolon and square brackets must be paired; those two requirements cannot be met by the example. There is no way to match that input to the grammar, therefore the input isn't an invalid @-rule, it simply isn't CSS. There are voices that say that eventually CSS should specify exactly how to parse any stream of bytes, so that every UA does exactly the same, no matter how little the input looks like CSS. But for the moment, CSS doesn't yet say how to treat this particular example. I think the task of the validator is to say that this input is invalid (of course), but how it recovers from the parsing error is mostly arbitrary.
Thank you for the clarification. On submission time, I obviously was misled by the wording of the CSS 2.1 spec: "An at-rule consists of everything up to and including the next semicolon (;) or the next block, whichever comes first.", where I construed 'everything' to mean just that. >But for the moment, CSS doesn't yet say how to treat this particular example. This is a somewhat unfortunate state (at least for implementors) in general, as for several other cases that do not match the generic grammar as well there *are* rules for how to recover (cf. CSS 2.1, 4.2, "Unexpected end of style sheet." and "Unexpected end of string.").