- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Mon, 6 Aug 2012 14:04:50 -0400
- 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 UTC