W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: [CSS 2.1] General at-blocks and error recovery

From: Bert Bos <bert@w3.org>
Date: Wed, 30 Jul 2008 17:25:52 +0200
To: "www-style@w3.org" <www-style@w3.org>
Message-Id: <200807301725.52535.bert@w3.org>

On Thursday 27 March 2008 19:03, L. David Baron wrote:
> On Saturday 2008-03-08 19:09 -0800, Justin Rogers wrote:
> > An at-rule consists of everything up to and including the next
> > semicolon (;) or the next block, whichever comes first.
> > <<<
> >
> > @media all { @ }
> > div { color: green; }
> >
> > I think the sticky point for this test case is what takes priority
> > in error recovery. The open parenthesis starts a block which is
> > owned by the @media. The closing parenthesis should close the block
> > because it is currently the only open block and we found a matching
> > closing character. We may do this while we are in error recovery
> > for something else like a selector though.
>
> This does make sense to me; I'm fine with changing Mozilla to do
> this.
>
> I think the way to fix this in the spec would be to make the
> following changes:
>
> In section 4.2, change:
>   # User agents must ignore an invalid at-keyword together with
>   # everything following it, up to and including the next semicolon
> (;) # or block ({...}), whichever comes first.
> to say:
>   # User agents must ignore an invalid at-keyword together with
>   # everything following it, up to and including the next semicolon
> (;), # the next block ({...}), or the end of the block (}) that
> contains # the invalid at-keyword, whichever comes first.
>
> In section 4.1.7, after the following:
>   # When a user agent can't parse the selector (i.e., it is not valid
>   # CSS 2.1), it must ignore the declaration block as well.
> add:
>   # If the block containing the selector is closed with a "}" before
>   # finding a declaration block, the rule set does not have a
>   # declaration block (so the user agent does not need to find one to
>   # ignore).

I'm fine with that, although it feels to me that it's redundant.

An @media rule is first of all an at-rule and '@media all { @ }' is 
indeed a valid at-rule. Secondly, the definition of @media imposes 
restrictions on two of the parts of that at-rule, in particular it says 
that there must be style rules between the curly braces.

That says to me that we take the part between the curly braces and try 
to see style rules in there. In this case we find something that looks 
like a selector and then the end of the text. That's not a rule and 
thus we ignore it. The result is that we end up with '@media all {}'.


Note, however, that neither my derivation nor David's proposed text 
above solve the original question of issue 32[1], which was about '@1; 
div {color: green}' As I explained[2], that text does not parse as CSS 
at all and thus the rules that try to ensure future extensibility do 
not apply.

But I could see CSS3 saying something saying like this:

If an input can be tokenized but doesn't match the core grammar, the UA 
may try to recover as follows: find the longest initial sequence of 
tokens that can be a valid initial sequence in the core CSS syntax and 
then replace the next token with a DELIM that is not used in CSS. Then 
parse again. This may be repeated until the input parses. (A concrete 
example of a possible DELIM is the BEL character, ASCII 7.)

Note: if there is no next token, then the rules for "unexpected end of 
file" may provide another way to recover.

In the case of '@1; div {color: green}', the longest initial sequence of 
tokens is: DELIM (@) + NUMBER (1). We thus replace the ";" with the 
character BEL (ASCII 7). Then the input parses, viz., as a ruleset. The 
selector of that ruleset is obviously not valid, because neither "@" 
nor BEL can occur in selectors, and thus the ruleset is ignored.

Another example is 'div {color: green}}'. The last "}" cannot be parsed, 
but if we replace it by a BEL, the file *can* be parsed and the 
BEL becomes a selector, which is then ignored, of course, because it is 
not a valid selector.

And a last example: 'div {color: -->}'. Syntactically, the "-->" cannot 
be a value, but if we replace it by BEL, then it can. Of course, BEL is 
not a legal value for 'color' and thus the declaration is ignored.

[1] http://csswg.inkedblade.net/spec/css2.1#issue-32
[2] http://www.w3.org/mid/200804091918.09364.bert@w3.org



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Wednesday, 30 July 2008 15:26:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT