- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Tue, 11 Apr 2017 16:29:21 -0400
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Cc: W3C www-style mailing list <www-style@w3.org>, W3C Public CSS Test suite mailing list <public-css-testsuite@w3.org>
Le 2017-04-11 11:15, Amelia Bellamy-Royds a écrit : > The test is correct for what it measures: whether `caption-side: left` > is a > valid declaration for an @supports rule, according to the CSS parser. > > That doesn't *always* mean that it is supported by the rendering engine > for > what you want. That test is trying to do exactly that: to check support of rendering engines, using a real property value that is not widely implemented in browsers. And doing so, I thought, would be a realistical and appropriate opportunity to use @supports in a real webpage development context. After all, this is the intended purpose of the spec: " The ‘@supports’ rule is a conditional group rule whose condition tests whether the user agent supports CSS property:value pairs. Authors can use it to write style sheets that use new features when available but degrade gracefully when those features are not supported. (...) " https://www.w3.org/TR/css3-conditional/#at-supports Generally speaking, " A supported property with an unsupported value must cause the @supports condition to fail. " http://test.csswg.org/suites/css-conditional-3_dev/nightly-unstable/html/css-supports-005.htm > Sometimes the parser supports a declaration, but the property is only > used > in certain situations. For example, there are lots of properties which > are > only used for SVG elements or only for HTML/CSS box-model elements, in > certain browsers. An `@supports` test cannot distinguish those cases. > It's a limitation of the way `@supports` is defined. > > For `caption-side`, my first guess was that maybe left and right are > supported, but only in vertical writing modes. Left and right are caption side values supported only by Firefox, in horizontal writing mode and in vertical writing modes: http://www.gtalbot.org/DHTMLSection/DynamicTableFormatting.html http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/CaptionSide-writing-modes-dhtml.html > But that does not appear to > be true, either: > > http://codepen.io/AmeliaBR/pen/jmNGym/ > > Since the Chrome CSS parser is claiming support, but there does not > appear > to be any underlying implementation, that's a serious bug to file on > Chrome. Have you filed? Have you received a response? I first wanted to know for sure if my test was correct. You see, Chrome 50+ has a 100% PASS success of all current tests involving @supports right now in the CSS3 Conditional rules test suite: https://test.csswg.org/harness/results/css-conditional-3_dev/ > ... > > On the broader issue of how this should affect CSS WG tests, that's a > lot > more complicated. CSS authors need to be able to rely on `@supports`! Exactly. There is a bunch of non-prefixed property and property values ('caption-side: top-outside', 'writing-mode: sideways-lr', etc.) that are supported and implemented by some browsers and that are not implemented in other browsers. Use of @supports conditional rule would then be useful if reliable. The state of tests in the CSS3 Conditional Rules test suite suggests as far as Chrome is involved that it is reliable .... but that test proves otherwise. > > The CSS WG could theoretically create `@supports` tests for every > CSS-defined property and property value, as part of the test suite for > each > property. The declaration should pass `@supports` if (and only if) it > also > passes the core tests for that property or value. > > But you can't write tests for every possible eventuality, measuring > `@supports` for every possible or proposed property or keyword value. Testing every possible 'property_name: property_value' declarations may not be wise or useful but testing those with dissimilar, divergent implementation among mainstream browsers makes sense: - text-orientation is not supported at all in MS-Edge versions - 4 caption-side values are not supported by Chrome 50+ and MS-Edge 15 - 2 writing-mode values are not supported by Chrome 50+ and MS-Edge 15 - font-size-adjust property is not supported by MS-Edge versions; under a trigger flag, it is in Chrome 50+ - and I am sure there are several others. > You > can therefore never test for certain that `@supports` never returns a > false > positive for non-standard features (and, as far as I can tell, > `caption-side: left` is non-standard 'caption-side: left' was standard in CSS 2.0: https://www.w3.org/TR/2008/REC-CSS2-20080411/tables.html#q6 Firefox and MS-Edge now support several -webkit- prefixed properties. > , although established enough to make > it to the MDN page). > > This is a persistent issue with any type of support-testing platform > feature: one bad implementation returning false positives makes the > feature > unreliable everywhere. It's why the `.hasFeature()` API is deprecated, > and > the SVG requiredFeatures attribute with it. I don't have any > suggestions > for how to fix it, beyond filing bugs whenever you find them, so that > the > number of affected browser versions is as small as possible. > > ~ABR I will file bugs. Amelia, thank you for your reply. Gérard > > On 10 April 2017 at 20:05, Gérard Talbot <www-style@gtalbot.org> wrote: > >> Hello, >> >> Is this test correct? >> >> http://www.gtalbot.org/BrowserBugsSection/CSS3ConditionalRul >> es/supports-caption-side-left.html >> >> Chrome 55+ claims to support 'caption-side: left' ... but that is not >> true, hence my question. >> >> http://lists.w3.org/Archives/Public/www-style/2017Mar/0073.html >> >> Gérard >> >> >> -- Writing Tests http://web-platform-tests.org/writing-tests/ General Test Guidelines http://web-platform-tests.org/writing-tests/general-guidelines.html Test Review Checklist http://web-platform-tests.org/reviewing-tests/checklist.html Test Templates http://web-platform-tests.org/appendix/test-templates.html Writing Reftests http://web-platform-tests.org/writing-tests/reftests.html
Received on Tuesday, 11 April 2017 20:30:03 UTC