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

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

From: L. David Baron <dbaron@dbaron.org>
Date: Fri, 7 Mar 2008 21:18:42 -0800
To: Anne van Kesteren <annevk@opera.com>, Brad Kemper <brkemper@comcast.net>, Justin Rogers <justrog@microsoft.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20080308051842.GB9348@ridley.dbaron.org>

[ replying to three messages in the same thread all at once ]

In summary, I didn't see anything in this thread suggesting that any
changes to the spec are needed.  The current spec says:

http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#at-rules :
  #  At-rules start with an at-keyword, an '@' character followed
  #  immediately by an identifier (for example, '@import', '@page').
  #
  # An at-rule consists of everything up to and including the next
  # semicolon (;) or the next block, whichever comes first. 

http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#parsing-errors :
  # Invalid at-keywords. 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.

These both apply the special recovery method only to @-rules, which
are clearly defined as starting with an @ followed immediately by an
identifier.

That said, all of my answers below are predicated on at least one of
the following two assumptions being true (although I'm reasonably
confident in the second one):
  (1) the rule in
http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#block and
redundantly in
http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#declaration and
http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#parsing-errors
(since property names and declarations are always inside blocks)
actually applies everywhere.  In other words, I assume a particular
resolution of http://csswg.inkedblade.net/spec/css2.1#issue-24 .
  (2) anything that starts with "{" is a block, per
http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#block

On Sunday 2008-01-27 13:27 +0100, Anne van Kesteren wrote:
>
> On Sun, 27 Jan 2008 05:20:56 +0100, Justin Rogers <justrog@microsoft.com> 
> wrote:
>> @1;
>> DIV { color: green; }
>
> In this case @1; is simply part of the (bogus) Selector,  as if it had read 
> "@1; DIV { color:green }". And bogus selectors along with their declaration 
> block get dropped.
>
> What Safari does is just a bug.

Agreed.

On Sunday 2008-01-27 13:14 -0800, Brad Kemper wrote:
> green in Safari and Opera (not FireFox):
>    @1; div { color:green; }

As Anne said, "@1; div" is an invalid selector, so this should be
dropped.

> or:
>    @1 []; div { color:green; }
>
> green in Opera only:
>    @1 [{}]; div { color:green; }

Likewise, both of these should be dropped.

> green in Opera only (with ALL subsequent rules seemingly ignored in Safari 
> and FireFox):
> @media all {
>    @
> }
> div { color:green; }

I think this one should produce green; this seems like a bug in
Firefox.

> green in Opera and Safari (with ALL subsequent rules seemingly ignored in 
> FireFox):
>    @1 { [ }
>    	div { color:green;}

There's an unclosed [ here, so all subsequent rules should be
ignored.

> on this last one, adding a "]" or ";"  anywhere after the first "}" does 
> not seem to help FireFox recover.

If you add an additional "] }" to the end of the first line, then
only the rule immediately following is ignored, and Firefox
continues parsing after it.  I think that's correct, since
"@1 { [ } ] } div" is an invalid selector (in which the first "}" is
ignored due to the open "]").

On Sunday 2008-01-27 13:40 -0800, Justin Rogers wrote:
> The @media production rule brings up another question. I read it as:
> 
> -- Most interesting of Brad's additional test cases
> @media all { /* open scope +1 */
>   @ /* invalid token, go into selector error recovery which looks for a block */
> } /* close scope from @media */
> 
> Because of the last scope closure, it ends the error recovery
> started at the invalid @ symbol (read as IMHO I think it should
> end the error recovery since others can certainly beg to differ).
> All subsequent rules after it should be parsed normally so I would
> say the DIV should be green.

Agreed.  I think it's a bug in Firefox that it needs a {} to recover
from a stray @ inside an @media rule.

> Adding a bracket after the closing brace closes the bracket scope,
> but still does not satisfy the brace scope. The final } in the
> file after color: green; is where we finally close the scope and
> error recovery is complete. This means the following file should
> work:
> 
>    @1 { [ } ]
>             div { color:green;}
>                 div  { color: green; } /* The last rule eaten was the first div selector above, while I'm safe */

You need one more "}" on the first line, as I gave above.

On Sunday 2008-01-27 14:11 -0800, Brad Kemper wrote:
> On Jan 27, 2008, at 1:40 PM, Justin Rogers wrote:
>> Adding a bracket after the closing brace closes the bracket scope, but 
>> still does not satisfy the brace scope. The final } in the file after 
>> color: green; is where we finally close the scope and error recovery is 
>> complete. This means the following file should work:
>>
>>    @1 { [ } ]
>>             div { color:green;}
>>                 div  { color: green; } /* The last rule eaten was the 
>> first div selector above, while I’m safe */
>
> That makes sense, except that FireFox never recovers from that either in my 
> tests. As near as I could tell, no number, combination, or placement of 
> closing braces and/or brackets after the first closing brace would help 
> FireFox recover (although I didn't spend the time to test exhaustively). 
> Perhaps it is a bug then, and maybe just in 3.0b2.

No, I think it's correct, as an additional "}" is needed on the
first line to actually close the first "{".

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Saturday, 8 March 2008 05:19:15 GMT

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