This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 891 - Semicolon should terminate blockless at-rule
Summary: Semicolon should terminate blockless at-rule
Alias: None
Product: CSSValidator
Classification: Unclassified
Component: Other (show other bugs)
Version: CSS Validator
Hardware: All All
: P3 minor
Target Milestone: ---
Assignee: Olivier Thereaux
QA Contact: qa-dev tracking
Depends on:
Reported: 2004-09-27 10:29 UTC by Christian Roth
Modified: 2006-04-25 10:24 UTC (History)
1 user (show)

See Also:


Description Christian Roth 2004-09-27 10:29:48 UTC
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.
Comment 1 Bert Bos 2006-04-25 09:22:53 UTC
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.
Comment 2 Christian Roth 2006-04-25 10:24:22 UTC
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.").