W3C home > Mailing lists > Public > public-css-testsuite@w3.org > September 2010

Re: Tests with difficult/confusing pass condition/wording: c414-flt-ln-002.htm

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Tue, 14 Sep 2010 17:16:53 -0700
Message-ID: <b5711de0fc1fe90b791207c1a1555eb6.squirrel@cp3.shieldhost.com>
To: "Geoffrey Sneddon" <gsneddon@opera.com>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>, "Řyvind Stenhaug" <oyvinds@opera.com>

> On 13/09/10 23:04, "Gérard Talbot" wrote:
>> Such problem, which has been corroborated by another poster in
>> www-style, may have caused you to say "I've almost never seen them
>> actually all get rendered on the same line".
>
> I've not actually tried to run any of the CSS 2.1 tests on Windows
> myself, so no. :)
>
> Our regression tracking system takes screenshots at 1600x1200 (by
> default), which is wide enough as to make D appear split between lines.
>
> My local browser ends up (after all the chrome around it) with a
> viewport of 902x643, which is narrow enough to make B appear split
> between lines.

B appear split?
Geoffrey, you must be referring to
http://test.csswg.org/suites/css2.1/20100815/html4/c414-flt-ln-002.htm
then .

I agreed that such testcase had too many boxes and that the testcase
would be more beneficial if it had less boxes.. I thought available
width was too tight for so many boxes. The test suite assumes a minimum
width of 640px for the viewport and a medium font size of 16px. Also I
thought such testcase should not mix left-floating boxes with
right-floating boxes.


> As far as I can tell, there are only a few ranges of width where it will
> actually end up with the big/small coloured boxes on the same line as
> each other.
>
> For
> <http://www.gtalbot.org/BrowserBugsSection/css21testsuite/c414-flt-ln-002-draft.htm>,
> I wonder if it is worthwhile setting an explicit width on the div and
> using Ahem so that it is predicable exactly where the lines will break.

I am not against such idea. Use of Ahem font will provide more control.

> I dislike, "You can resize the window to change respective position of
> boxes and you can increase/decrease the font size to verify", as it is
> impossible to do within any regression tracking system pretty much.

Even if I did not write that, testers do not have the same monitor
screen width, screen resolution, default medium font-size and/or minimum
font size values; they do not have to run tests in a maximized window,
etc.

> Given a screenshot, you can't just increase/decrease font size to
> verify. It's also pretty much impossible to change such a test into a
> reftest. In general, having a TC that's pretty much impossible to
> automate seems bad.


It's not possible (albeit preferable) to have all testcases automatable
and also regression-trackable. I assume that a wide majority of
testcases, including the 9.5.x float ones, can be automatable (...
especially those which do not have the "interact" flag). Maybe not those
c414-flt-ln-00?.htm testcases.

I originally was trying to "restaure" or improve the Ian Hickson
c414-flt-ln-002 testcase.

IMO, a good testcase will still be reliable, trustworthy even if font
size is decreased|increased within reasonable limits and/or if window
viewport is resized. In real life, people adjust font size, viewport,
colors, increase this and turn off that, change screen resolution, etc..

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

CSS 2.1 test suite (beta 3; August 15th 2010):
http://test.csswg.org/suites/css2.1/20100815/html4/toc.html

CSS 2.1 test suite contributors:
http://test.csswg.org/source/contributors/
Received on Wednesday, 15 September 2010 00:17:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 September 2010 17:52:03 GMT