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

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.


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

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
- 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
- "API" is not required in title in

> [1]
> [2]
> On 10/16/12 10:31 PM, "Gérard Talbot" <>
> 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:
>>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)
>>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.
>>Contributions to the CSS 2.1 test suite:
>>CSS 2.1 Test suite RC6, March 23rd 2011:
>>CSS 2.1 test suite harness:
>>Contributing to to CSS 2.1 test suite:

Contributions to the CSS 2.1 test suite:

CSS 2.1 Test suite RC6, March 23rd 2011:

CSS 2.1 test suite harness:

Contributing to to CSS 2.1 test suite:

Received on Wednesday, 17 October 2012 23:55:49 UTC