Re: [RC6] rgb(50%, ..., ...) or rgb(..., 50%, ...) or rgb(..., ..., 50%): fractional value!

Le Mer 5 décembre 2012 19:25, Rebecca Hauck a écrit :
> Hi Gérard & Arron,
>
>
> I encountered many of these tests when scrubbing the list of things we
> want to fix for the CSS2.1 Test Suite 2.0 release. In fact, there are
> ~100
> tests with this issue  so coming up with a solution to this have a big
> impact on the overall todo list.
>
> After looking at them, I noticed that all of them except for those named
> background-color-* use the same rgb() syntax for both the test and
> reference elements.


Rebecca,

Correct. All of them except those named background-color-* use the same
rgb() syntax for both the test and reference elements.

If the test is about color (and border-[bottom|left|right|top]-color,
background-color, outline-color are tests about color), then its
associated reftest should be using another method, a different method
for expressing/rendering such color. So, if both the test and reftest
are using rgb(%, %, %) and comparing a color with a background-color,
then it is *not* using a different method, another method of expressing
colors, of rendering colors and for comparing colors.

So,

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/color-049.htm

can never actually fail.


>
> Example: border-bottom-color-049 has:
>
>      #test
>      {
> 	border-bottom-style: solid;
> 	border-bottom-width: 1in;
>         border-bottom-color: rgb(1%, 1%, 1%);
>         height: 0;
>      }
>
>      #reference
>      {
>         background-color: rgb(1%, 1%, 1%);
>         margin-top: 10px;
>      }
>
>
>
> First point:
> The way this is written, is the fractional color value really a
> precision
> issue? In other words, whether the UA rounds up or down, isn't it fair
> to
> assume that it'd do the same thing for both the test and reference
> elements so they'd always match?


It is fair to assume that it will do the same rounding (up or down) for
both the test and reference and so they should *always* match: in fact,
this is already verifiable and verified too. A consequence of this is
that, eg.

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/color-049.htm

can never actually fail.


> Or am I missing something here?
>
>
> Second point:
> However, does this expose a different weakness in the test?


I think it does expose a weakness in the test. An automated checking of
background-color-* test (software comparing screenshots) would
eventually report failures that no human eyes would be able to
see/notice to begin with.

rgb(1%, 1%, 1%) is *not* #020202 in some browsers.


rgb(1%, 1%, 1%) is equivalent to #020202 in some other browsers.

Therefore, there is a weakness in the test which can be explained.

The thing is:

background-color-049 would eventually be reported as a failure by some
browsers while color-049 would never be reported as a failure by any/all
browsers.

So, we're not even consistent in doing tests and we're not really doing
good testing either.


> Since this
> is
> testing rgb() with % args with a particular property in focus, is it an
> accepted practice to use the same input for the reference rendering
> using
> a different property?


A different property: yes, in a very wide majority of tests and
situations. But here, what annoyed me from the beginning is that we are
comparing 2 colors with the same feature, with the same method of
"creating" such color code, which is rgb(%, %, %).


> I understand you must make assumptions about the
> behavior or stability of everything you use in a test file. But if this
> test failed, it would be difficult to tell right away where the point of
> failure is - the test property, the ref property or the rgb() value.  If
> it is indeed acceptable to construct a test this way, then my first
> point
> still stands.
>
> Third point:
> Specifically for the tests with 50% values - Nothing about those tests
> is
> special to 50%. I think these can be changed to 20%,40%,60% or 80% and
> compared to non-fractional rgb values (that is, if the %'s need to be
> removed at all)


Those percentage numbers are good numbers:

rgb(20%, 20%, 20%) == #333333  (20% of 255 == 51)

rgb(40%, 40%, 40%) == #666666  (40% of 255 == 102)

rgb(60%, 60%, 60%) == #999999  (60% of 255 == 153)

rgb(80%, 80%, 80%) == #CCCCCC  (80% of 255 == 204)


>
> The tests named background-color-* all use pngs as a reference, so those
> are definitely problematic. Changing the 50% tests to 40% would fix some
> of them, but I don't have a solution for those testing 1% and 99%.
>
> And, speaking briefly about it with Arron this morning, I understand
> there
> are several hundred more that have this issue - basically all
> color-related tests, so this extends wider than what we currently have
> identified for the 2.0 release.
>
> Thoughts?

Proposal

a) remove all the tests with rgb(1%, , ) or with rgb( , 1%, ) or with
rgb( , , 1%) and with rgb(99%, , ) or with rgb( , 99%, ) or with rgb( ,
, 99%)
b) convert the ones using rgb(50%, , ) or with rgb( , 50%, ) or with
rgb( , , 50%) to be using 40% instead
c) create support files with #660000, #006600, #000066 and #666666


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 Thursday, 6 December 2012 01:50:54 UTC