- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Mon, 6 Aug 2012 14:23:43 -0400
- To: "Florian Rivoal" <florianr@opera.com>
- Cc: "Public CSS test suite mailing list" <public-css-testsuite@w3.org>
Le Lun 6 août 2012 5:08, Florian Rivoal a écrit : > 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; } > Florian, Then IE8 or most/any browser without @supports implementation would pass such code: that's the problem I see and believe should be avoided, worked around. >> --------------------- >> >> 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. [snipped] How about the following proposed replacement code for at-supports-022.html then: <style> div { background-color: red; height: 100px; width: 100px; } @supports [margin: 0] { div { background-color: red !important; } } @supports (margin: 1px) { div {background-color: green; } } </style> Gérard P.S. I must go now; I will read the rest of your email and your other email later. -- Contributions to the CSS 2.1 test suite: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/ CSS 2.1 Test suite RC6, March 23rd 2011: http://test.csswg.org/suites/css2.1/20110323/html4/toc.html CSS 2.1 test suite harness: http://test.csswg.org/harness/ Contributing to to CSS 2.1 test suite: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Monday, 6 August 2012 18:24:14 UTC