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

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

CSS 2.1 test suite (beta 3; August 15th 2010):

CSS 2.1 test suite contributors:
Received on Wednesday, 15 September 2010 00:17:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:20 UTC