- 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