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

Re: Tolerance of 1px on each side for anti-aliasing: feedback requested

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Wed, 17 Oct 2012 19:55:17 -0400
Message-ID: <8022cae3f5559554860e0795d77b7d84.squirrel@ed-sh-cp3.entirelydigital.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 17 October 2012 23:55:51 GMT