- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Wed, 17 Oct 2012 19:55:17 -0400
- To: "Rebecca Hauck" <rhauck@adobe.com>
- Cc: "Public CSS testsuite mailing list" <public-css-testsuite@w3.org>
Le Mer 17 octobre 2012 17:06, Rebecca Hauck a écrit : > Hi Gerard, > > As the author of that tutorial (and many of the tests in the suite upon > which the tutorial is based - CSS Transforms), I can give you the > background on why we did this. > > UAs differ in the way they implement CSS Transforms. While some > implementations use double precision, others use fixed point numbers. > This > naturally lead to slightly different results. We actually had a bug > report > for the specs because of rounding issues [1]. > Therefore, we cannot assume or guarantee pixel perfect rendering on all > UAs and will almost always have anti-aliasing. This is especially true > for > particular transforms such as rotate or skew. Rebecca, Rounding issues is one thing. Testing rotate or skew in CSS Transforms tests is another. An anti-aliasing is another. Whenever we met an rounding issue in CSS 2.1 test suite, we tried to elegantly work around such issue. Without adding a 2px margin of error. The tutorial seems to be promoting a way to work around some particular situations which are unique to CSS Transforms; I do not think it should be promoted as a normal way to create test *_for all CSS3 modules_* and for any of the 3 situations listed above. > Additionally, since > transforms behave by moving an element from one point to another, the > best > way to construct reftests is to place a red shape in the exact position > beneath that of a correctly transformed element. Being the best way to > design a reftest may be somewhat unique to transforms, but I'm not > familiar enough with all of the other CSS features to say for sure. > Lastly, when we submitted our first batch of these tests, this method > was > actually recommended to us here on this list [2]. > > I definitely don¹t think this should be discouraged or disallowed as it > is > clearly the best way to test transforms. Maybe it is the best way to test some (many? all?) Transforms features but my opinion is that it should not be a normal, standard way of coding an ordinary red-square being overlapped by a green-square. > Whether it should be > encouraged > is another question I can't really comment on without fully > understanding > the best way to test every CSS feature. If there is an objection to > having > transforms as the basis for the tutorial you referenced, I'm happy to > either change it or qualify that the tutorial was used for Test the Web > Forward where we were featuring that spec. My main concern is that adding a 2px margin of error should *only* be done if there isn't any other way to achieve the target/goal of a test. It should be an exception, not a standard thing to do in green shape overlapping red shape kind of test. > In short, it probably should be a method that is considered on a case by > case basis. More generally, anything that makes a more robust, reliable > test should always be allowed. :) It should be accurate too. When there is no rounding issue or antialiasing involved, then it should not be lenient, tolerant. > Cheers, > -Rebecca http://tallshort.github.com/web-platform/presentations/test-the-web-forward-tutorial/index_cn.html#/13 5 issues: - listing properties in alphabetical order helps reviewer - top and left declarations have no units: this coding error occurs in 3 other slides (eg http://tallshort.github.com/web-platform/presentations/test-the-web-forward-tutorial/index_cn.html#/18 ) - using a class for the element seems not be needed if there is only 1 element on which the rule applies; class is for logical grouping of several elements, id is for unique element in document - absolute positioning is often overused (on the web and in test suites) and it is not as reliable as relative positioning - 101 versus 98: this tutorial slide promotes/suggests leniency and not accuracy. It should be presented as an exceptional workaround required by the test. By the way, I see other minor issues in other slides: - 1 extra ">" in http://tallshort.github.com/web-platform/presentations/test-the-web-forward-tutorial/index_cn.html#/35 - "API" is not required in title in http://tallshort.github.com/web-platform/presentations/test-the-web-forward-tutorial/index_cn.html#/34 > > [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15709 > [2] > http://lists.w3.org/Archives/Public/public-css-testsuite/2012Apr/0076.html > > > > On 10/16/12 10:31 PM, "Gérard Talbot" <css21testsuite@gtalbot.org> > wrote: > >>Hello all, >> >>I wish to know if we should allow to allocate 1px (as a margin of error >>or latitude) on each side of squares, rectangles, etc.. to take into >>account anti-aliasing. >> >>Personally, I have never done that, this never happened in CSS 2.1 test >>suite as far as I know and the most active contributors do not do that. >> >>Typically, what is being done is: >> >> #overlapped-red { >> background: red; >> position: absolute; >> top: 1px; >> left: 1px; >> width: 158px; >> height: 158px; >> } >> >> #overlapping-green { >> background: green; >> position: absolute; >> top: 0px; >> left: 0px; >> width: 160px; >> height: 160px; >> } >> >>so that the overlapping green is 2px wider and 2px taller than the >>overlapped red. The painting covers more area than needed. Furthermore, >>this way of coding is in a ttwf tutorial: >> >>http://test.csswg.org/source/contributors/ttwf/samples/ttwf-reftest-tutori >>al-001.html >> >>Should we allow (tolerate) this, encourage this or disallow this? >> >>Why would doing this be necessary anyway, to begin with? >> >>-------- >> >>Sometimes, consequences of rounding effects could be misinterpreted as >>anti-aliasing effects. >> >>Eg. (to be viewed with Opera 12.02) >> >>http://www.gtalbot.org/BrowserBugsSection/review/background-size-xyz.html >> >>Rescaling from 60px to 100px implies an increase of 66.66666% and so >>rounding down of percentage and then rounding down of fractional pixel >>seem to occur for Opera 12.02 in such test. >> >>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-contr >>ibutions-css21-testsuite.html >> >> > > -- 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 Wednesday, 17 October 2012 23:55:49 UTC