RE: FW: In a quick glance, all of the whitespace test file are invalid tests that don't prove anything

Hello all,

>> Gérard Talbot wrote:

>> This is the same problem with testcases which expect the tester to be
>> able to
>> see, measure (or compare) a 9px (or 12px or 18px) difference between 2
>> objects with the naked eye.
>

> Arron Eicholz wrote:
> I don't know of any cases that you are referring to here

Arron, I was referring to these testcases

http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-00-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-01-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-02-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-03-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-04-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-05-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-06-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-07-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-08-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-09-b.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1508-c527-font-10-c.htm

which I mentioned and commented in my January 25th 2010 email with
subject line:
"
t1508-c527-font-00-b.htm to t1508-c527-font-10-c.htm: Testcases pass
condition are not self-evident
"

http://lists.w3.org/Archives/Public/public-css-testsuite/2010Jan/0043.html


> but I would be
> happy to address those cases if you call them out (note I haven't gotten
> a chance to address any issues since 2/9 so I am a bit behind on
> feedback if you already called them out).


No problem. I will call them out when I encounter them.


>>
>> > Plus, we should have images that are exact measurements.  One for
>> mm,
>> > one for inches, etc.  So if an end result of a test is supposed to
>> > have a space of 10mm, the tester can clearly see that the end
>> results
>> > are 10 mm.
>>
>> Creating custom (vertical and horizontal) measurement rulers (for in,
>> mm,
>> cm, px, etc.) is rather easy to do. I have submitted 2 for the test
>> suite.
>>
>
> Rulers are a great idea but you forget a couple major issues with using
> images. Zooming and HighDPI. These two features do not have any
> guidelines on how they should react on images. Are they required to
> scale the images? I say yes but that then can possibly change image
> rendering a 1px line into 2px or more. That is problematic. Using rulers
> restricts us from testing zooming and HighDPI scenarios with the same
> tests that we have already created. This is one reason why the '96dpi'
> flag was created because of this particular issue. That flag defines
> that the tests is only valid in that specific DPI setting and may not
> work in other DPI settings.


I try to follow as strictly as possible the assumptions for the CSS 2.1
test suite. So,

Zooming: I never use this, never test this, never bother with such
feature and there is nothing mentioned about zooming in the test suite
assumptions. I am not sure CSS 2.1 testsuite testcases should still be
workable and reliable if zoom feature (magnification of the whole
webpage, not just text size increase) is activated.

HighDPI: there is now 8777 test entries in the test suite now. I
personally only test with 96dpi. If we have to start testing with
zooming and/or with various dpi settings, then such kind of testing will
require appropriate software for such kind of testing.

>> What is unacceptable is that a few testcases expect user agents to be
>> able to
>> render distance like 2.54mm (9.6px) or 15.24mm (or 57.6px) precisely
>> and
>> then ask/invite the tester to check if there is red in the page.
>>
>> There is no normative restraint or requirement regarding how fraction
>> of a
>> pixel is supposed to be handled by user agents. Each/all user agents
>> have
>> implementation limits and various capability limitations.
>
> If there are cases that have this fractional pixel problem let me know.

If I see another testcase with such fractional pixel problem, I will let
you know.

> I know I have been trying to track all of them down and fix them.

Yes, Arron, you have.

http://www.w3.org/Style/CSS/Test/CSS2.1/20100127/html4/margin-006.htm
is one example which was reported in
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Jan/0062.html
and it was corrected in
http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_8/margin-006.htm

Regarding the 57.6px example, please consult

http://lists.w3.org/Archives/Public/public-css-testsuite/2010Feb/0030.html

and look for "top: 0.6in;" in

http://www.w3.org/Style/CSS/Test/CSS2.1/20100127/html4/vertical-align-116.htm

http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_10/vertical-align-116.xht



One last comment. Specifically regarding Microsoft's line-height
testcases: there are lots of testcases inviting the tester to compare 2
small black boxes' height and then establish if the 2 small black boxes
are the same height (e.g.:
http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_10/line-height-002.htm
I personally believe that those testcases are definitely not ideal.

best regards, Gérard Talbot
-- 
Contributions to the CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

CSS 2.1 test suite (alpha 1; January 27th 2010):
http://www.w3.org/Style/CSS/Test/CSS2.1/20100127/html4/toc.htm

CSS 2.1 test suite contributors:
http://test.csswg.org/source/contributors/

Received on Tuesday, 2 March 2010 18:51:09 UTC