W3C home > Mailing lists > Public > public-css-testsuite@w3.org > August 2012

Re: [css3-conditional] Submitted a few TCs

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Mon, 6 Aug 2012 14:04:50 -0400
Message-ID: <15c67db4ae2dc942c562bdb8f341a88e.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Florian Rivoal" <florianr@opera.com>
Cc: "Public CSS testsuite mailing list" <public-css-testsuite@w3.org>

Le Lun 6 août 2012 4:47, Florian Rivoal a écrit :
> On Sat, 04 Aug 2012 13:59:55 +0200, Gérard Talbot
> <css21testsuite@gtalbot.org> wrote:
>
>>
>> Le Jeu 2 août 2012 8:22, Florian Rivoal a écrit :
>>> Hi,
>>>
>>> I've submitted a few TCs for @supports in
>>> contributors/opera/submitted/css3-conditional/
>>
>> http://test.csswg.org/source/contributors/opera/submitted/css3-conditional/
>>
>>
>> Florian,
>>
>> The nr 1 problem I see right now with those 33 tests is that 19 of
>> them
>> will pass in browsers which have no implemention of @supports
>> conditional rule. So, these 19 tests have limited relevance,
>> worthiness
>> and weak trustworthiness.
>
> These tests were useful to me when implementing, and quite a few of them
> failed on early stages of the implementation.
> Of course, they will already pass on a (correctly implemented) browser
> that does not have @support at all, but incorrect implementation of
> @supports can cause them to fail.
>
> More than testing @supports, they are testing the error recovery
> mechanism
> of the parser, so I find it acceptable that they pass on browsers
> without
> @supports.

I disagree. Most of those tests can be coded to display a red square
if/when there is no @supports implementation.

>
> If if you disagree, I can see 1 alternative way to write them so that
> they
> fail on browsers without @supports.
> Instead of:
>
> div { height:100px; width:100px; }
> @supports (margin: ) { div { background-color:red; } }
> div { background-color:green; }
>
> I could write:
>
> div { height:100px; width:100px; }
> @supports (margin: ) { div { background-color:red !important; } }
> @supports (width: 0) { div { background-color:green; } }
>
> It would result in green on correct implementations, red on incorrect
> ones, and nothing when there is no implementation,
> so maybe that is
> better.

Why not:

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

or even

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


A red square will be displayed if/when there is no @supports
implementation.


> On the other hand, this is a less minimal TC, and it isn't as
> obvious what is being tested

If the design and working logic of a test is not obvious, then the
assert text should be used for, can help, compensate. Or even add more
explanations in /* comments */.

> , or what is wrong if something fails.

If a red square is displayed, then, yes, the failure could be caused by
incorrect implementation or absence of implementation or even a side
effect like incorrect specificity implementation.

But I think the test suite should not allow weak web-standards-browsers
to pass 19 tests out of 33 tests.

Gérard
-- 
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:05:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 August 2012 18:05:31 GMT