Re: [css3-conditional] at-supports-020, at-supports-021 and at-supports-024

Le Lun 6 août 2012 5:33, Florian Rivoal a écrit :
> Hello,
>
>
>> http://test.csswg.org/source/contributors/opera/submitted/css3-conditional/at-supports-020.html
>> http://test.csswg.org/source/contributors/opera/submitted/css3-conditional/at-supports-021.html
>> http://test.csswg.org/source/contributors/opera/submitted/css3-conditional/at-supports-024.html
>
> As I said in the other mail, I agree that putting background-color:green
> inside a (passing) @supports
> would prevent implementations without @support from passing.
>
> However, even if they use some broken @support constructs, these tests
> are
> focusing on the parser's error recovery, not on @support itself.
>
> I think whether or not we should make them fail on browsers with a
> properly error recovering parser but without @support  depends on what
> we
> think the goal of the tests is.
>
> If the goal of the tests is to expose potential implementation flaws, I
> think it is ok for them to pass on browsers on browsers with a properly
> error recovering parser but without @support.

Florian,

It may be ok ... but 19 tests out of 33 is a rather high percentage of
them.

I know that a good chunk of those 19 tests could be tuned to test error
recovery while also failing for user agents without @supports
implementation.


> If the goal is to measure how complete and correct an implementation of
> @support is, it is better for them to fail on non supporting browsers.
>
> Tests can never prove the absence of problems by passing

That's an interesting statement, with which I agree.

>, only the
> presence of problems by failing, and I was interested in finding flaws
> in
> my implementation, so I took the first approach.

I think 2 minimal requirements of tests - which we may not have explicit
so far - is

1- as a general rule, CSS tests should fail if CSS support is disabled

2- as a general rule, tests targeting implementation of a particular
feature (say, the clear property) should fail if such particular feature
is turn off or is reset to its default value.

There are examples of tests which do not achieve this: this makes such
tests rather weak, not entirely reliable, not very trustworthy.


> Also, since error recovery is supposed to cause a browser to recover
> identically from these situations regardless of whether it implements at
> supports or not, having the tests pass on a correctly implemented
> browser
> lacking @supports was
> useful to validate my understanding of parser recovery.
>
> That said, w3c test suites are likely to be used by random third parties
> to say "browser A's implementation of @supports scores x%, while browser
> B
> scores y%, therefore A is better than B". So I suppose the corrections
> you
> propose are worth doing.

Some browser manufacturers are known to do (advertisement claims in
their support webpages) the same when they release newer versions of
their browser.

>
>> PS. Btw, I now understand what "parens" means: it's a diminutive form
>> of
>> the plural of parenthesis.
>
> That's what it is. I hear it so often that I thought it was now accepted
> mainstream usage. Maybe not.

CSS 2.1 was using "parenthesis" and "parentheses". Now CSS 3 is using
"parens" and this was the first time I ever saw such word.

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 Tuesday, 7 August 2012 20:52:04 UTC