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

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

From: Rebecca Hauck <rhauck@adobe.com>
Date: Wed, 5 Dec 2012 16:25:32 -0800
To: Gérard Talbot <css21testsuite@gtalbot.org>, Arron Eicholz <arron.eicholz@microsoft.com>
CC: Public CSS test suite mailing list <public-css-testsuite@w3.org>
Message-ID: <CCE51E13.23C81%rhauck@adobe.com>
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.

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? Or am I missing something here?


Second point:
However, does this expose a different weakness in the test? 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?  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)


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?

-Rebecca



On 11/19/12 7:23 PM, "Gérard Talbot" <css21testsuite@gtalbot.org> wrote:

>Arron,
>
>A number of tests are testing color with 50% as one of the 3 values in a
>rgb( ,  , ) declaration. Now, if 100% is FF or 255, then what is 50%?
>Firefox 16.0.2 and Opera 12.10 resolve this as 128 and 80 respectively
>but Chrome resolves this as 7F (or 127)!
>
>This is simply because 255 / 2 == 127.5
>
>So, I will re-visit a bunch of tests like
>
>background-color, border-bottom-color, border-left-color,
>border-right-color, border-top-color, color, outline-color
>with the suffixed numbers 052, 053, 073, 074, 093, 094 and possibly more.
>
>An human would not and could not see such tiny color difference but this
>issue would most likely have been reported in an automated testing,
>checking of comparing screenshots.
>
>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
>
>
Received on Thursday, 6 December 2012 00:26:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 December 2012 00:26:04 GMT