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

On Wednesday, December 05, 2012 4:26 PM Rebecca Hauck wrote:
> 
> 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?
> 

Nope this is not a precision issue for any of these cases except when explicitly testing against the reference that is an image or a different color value format.

> 
> 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.
> 

No this does not expose a weakness in the test. This is how reference tests are written. We test if the similar functionality is working the same as other similar functionality somewhere else. In this case we are testing background-color against border-bottom-color both happen to be something "color", thus we test them in a way that can verify that border-bottom-color is accurate to our baseline which is background-color. An image is used to verify the actual property for background-color. Since those cases test against an image we know if those pass all the other cases testing against background-color can be verified correctly.

> 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)
> 

Sounds fine to me to change them to something that isn’t fractional. Though this only affects background-color cases really since those are the only ones that have the precision problem since they are compared to the image. Note we should double check all the other cases to confirm that they are not compared to other color formats.

> 
> 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%.

The 99% case and the 1% case show a problem with the spec. These cases specifically are testing boundary conditions and in order to do proper boundary testing you should do +1 and -1 of minimum and maximum values. We then end up in this case where we have 1% and 99%. Since these end up fractional we have a few options.

1. Remove percentage from the spec since it is untestable and cannot be interoperable because we do not define rounding correctly or how scenarios like these case be verified.
2. Define rounding of color values explicitly. Right now the spec only says that values can be approximate, section 6.1.4. In my opinion rounding is the way we approximate things for this case. That is at least how every photo editing program works that I have ever tested.
3. Update the background-color cases to have 2 references one ref that is on either side of the value being defined.

> 
> 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.
> 

Maybe not hundreds more I did some further investigation and it seems like we have most of the issues covered here. Depending on what we resolve out of this we may not have to worry about any other cases.

--
Thanks,
Arron Eicholz

> 
> 
> 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-

> co
> >ntr
> >ibutions-css21-testsuite.html
> >
> >
> 
>

Received on Thursday, 6 December 2012 18:31:55 UTC