Re: [css3-conditional] Submitted a few TCs: at-supports-019, at-supports-022 and at-supports-027

On Fri, 03 Aug 2012 21:43:51 +0200, Gérard Talbot  
<css21testsuite@gtalbot.org> wrote:

> "
> Finally, sort by order specified: if two declarations have the same
> weight, origin and specificity, the latter specified wins.
> "
> http://www.w3.org/TR/CSS21/cascade.html#cascading-order
>
> "
> Order of appearance. The last declaration wins.
> "
> http://www.w3.org/TR/css3-cascade/#cascading



> Proposal
> --------
>
> line 11: <style>
>    div {
>                                 background-color:red;
> /* You want the test to identify user agents which have
> no support for @supports */
>     height:100px;
>     width:100px;
>    }
>    @supports (margin: 4px) {
>     div { background-color:green; }
>    }
>
>
>    @supports (margin: ) {
>     div { background-color:red; }
>    }
>   </style>

I don't think this would preserve the purpose of the test. It would  
correctly check that the parser does not apply red, but it would not check  
that the parser recovers at the right place after the error. Instead, how  
about this using !important or a higher specificity selector on  
background-color:red? Like this:

div { height:100px; width:100px; }
@supports (margin: ) { div { background-color:red !important; } }
div { background-color:green; }

> ---------------------
>
> http://test.csswg.org/source/contributors/opera/submitted/css3-conditional/at-supports-022.html
>
>   <style>
>    div {
>     height:100px;
>     width:100px;
>    }
>    @supports [margin: 0] {
>     div { background-color:red; }
>    }
>    div { background-color:green; }
>   </style>
>
> Same thing here. If squared brackets is incorrectly honored when parsing
> the @supports rule, then it will not make a difference since
> background-color is redefined again in the last rule. So, the test - it
> seems to me - will not identify faulty, incorrect implementations.

You are right, this is problematic. Like the previous test, higher  
specificity or !important would fix it I think.

> http://test.csswg.org/source/contributors/opera/submitted/css3-conditional/at-supports-027.html
>
>   <style>
>    div {
>     background-color:green;
>     height:100px;
>     width:100px;
>    }
>    @supports (margin: 0)
>   </style>
>
> This test can *_never_* fail. There is no possibility that red can be
> displayed. As coded, IE4 will pass this test.

Actually, it can fail, and I have it because my implementation failed it  
at some point. When it fails, it will not display red, but it will not  
display green either. Maybe I should change the text to "Test passes if  
there is a filled green square" without mentioning anything about red.

Here is how it failed for me: when the parser does not find the opening  
'{' after '@supports (margin: 0)', it consumes everything up to the next  
properly nested ';' or '}', or EOF. In this case, it consumes the EOF.  
After that, the parser tries to resume normal operation, and using a  
grammar that looks something like: <style_rule> | <at_rule> | .... | EOF.
Since EOF has already been consumed, the parser finds nothing, fails, and  
discards the entire style-sheet, since it has no error recovery rule for  
missing EOF.

  - Florian

Received on Monday, 6 August 2012 09:08:50 UTC