W3C home > Mailing lists > Public > www-style@w3.org > December 2007

Re: [CSS 2.1] Request for links to additional error recovery parser tests

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 25 Dec 2007 13:56:23 +0100
To: "Justin Rogers" <justrog@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.t3v579ft64w2qv@annevk-t60.oslo.opera.com>

On Fri, 21 Dec 2007 01:15:10 +0100, Justin Rogers <justrog@microsoft.com>  
wrote:
> I've done some basic homework and pulled up a few of the public suites  
> for error recovery but nothing shows up as really complex. I'm  
> specifically trying to find test cases for matching pairs of  
> braces/blocks/parens.
>
> style="color: red }; background-color: green;"
>
> Opera/Safari treat the } as the end of the style block. Perhaps by  
> implying a { at the beginning, but they don't parse after the } at all.
> FireFox will throw out the color: red and apply the background-color:  
> green as if it realizes color as an invalid property.
> IE 7 and less will apply both properties.

Per HTML5 the contents of style= have to be parsed as the body of a  
declaration block. Given the following:

   <!DOCTYPE html>
    <style>
     body { background:red &; background:lime }
    </style>
    <p>This page should have a green background.

it seems to me that what Firefox does is most correct, but it depends on  
how HTML defines this in the end I think.


> [...] The interesting nesting/pairing problem then becomes, is the  
> nesting/pairing count a true stack or not? In other words: [...]

That does indeed seem not very well defined in the specification.


> I think making sure that the current nesting token matches the top of  
> the stack is correct and the other tokens are thrown out meaning we  
> don't actually close the scope and therefore we can't recover in this  
> case. All browser but IE end up with something here.
>
> DIV
> {
>                 color: red;
>                 color: [ ( {
>                 ] ) }
>                 ;
>
>                 color: green;
> }

I get the same in Firefox and a recent Opera here. Both red. (Which makes  
sense as per below because the ) ] sequence is not closed.)


> Fixing this would imply the following test case which FireFox/Opera  
> pass, Safari (3.0 for Windows)/IE fails.
>
> DIV
> {
>     color: red;
>     color: [ ( {
>     ] ) } ) ]
>     ;
>
>     color: green;
> }

So the algorithm seems to be that you keep a stack and that to pop an item  
of the stack you have to encounter a matching token. Any other token is  
ignored.

Given [ ( { as input you then start looking for } basically. Which would  
mean that ] ) at the start are ignored and that the } following thoses  
pops { from the stack, etc.


> This gets worse if you mix the declaration and ruleset recovery  
> together. The following should technically close the first ruleset and  
> the next one should probably be valid... However, mixed bag of responses  
> on this one from all browsers.
>
> DIV
> {
>     color: red;
>     color: [ ( {
>     ] ) } ) ]
> }
>
> DIV
> {
>     color: green;
> }

Actually, I get green in Opera, Firefox, and IE7. Can't test WebKit at the  
moment.


> You can trigger additional odd behavior by supplementing the } that  
> closes the first DIV block with more }'s and see that it can further  
> change behavior. One extra and Opera (9.50 beta) was going red.  
> Apparently count(}) mod 2 swaps the behavior back and forth.
>
> DIV
> {
>     color: red;
>     color: [ ( {
>     ] ) } ) ]
> }
>
> }
>
> DIV
> {
>     color: green;
> }

The situation you are testing here is more simple:

  DIV { color: red }

  } DIV { color: green; }

The } becomes part of the selector of the second declartion block  
basically which makes that declaration block ignored for obvious reasons.  
The behavior you see in Opera (the mod 2 thingie) and IE7 is a bug. I'll  
file a bug on Opera :-)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Tuesday, 25 December 2007 12:54:27 GMT

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