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

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

From: Florian Rivoal <florianr@opera.com>
Date: Mon, 06 Aug 2012 11:33:23 +0200
To: GĂ©rard Talbot <css21testsuite@gtalbot.org>
Cc: "Public CSS test suite mailing list" <public-css-testsuite@w3.org>
Message-ID: <op.wil4txyo4p7avi@localhost.localdomain>
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.

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, only the  
presence of problems by failing, and I was interested in finding flaws in  
my implementation, so I took the first approach.

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.

> 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.
Received on Monday, 6 August 2012 09:34:00 GMT

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