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

Tests with difficult/confusing pass condition/wording

From: Řyvind Stenhaug <oyvinds@opera.com>
Date: Wed, 08 Sep 2010 16:15:08 +0200
To: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <op.vipwjibmru61ud@oyvinds-desktop>

the following lists a number of tests that were found to be confusing with  
regard to determining a test result.

(Authors mentioned: CSS1 Test Suite Contributors, Elika J. Etemad, Gérard  
Talbot, Hilbrand Edskes, Ian Hickson, James Hopkins, Microsoft, Richard  

==== CSS1 Test Suite Contributors, Ian Hickson ====

* The description is too complicated, and it's difficult to tell easily if  
things are really level. Maybe this can be split up into multiple simpler  
* Says "unless there is not enough room for the big box to fit on the  
small box's line after the small box" - but in fact some of the big boxes  
are /left/-floated
* "big coloured boxes should be level with the top of..." (assuming it's  
meant that the top border edges of the two boxes should be level) - not  
necessarily true. The float's top may not be higher than the top of the  
span's linebox, so the TC seems to assume that 1.3em lineheight is exactly  
enough space for a medium border.

Wording can be confusing. "just the green outline of an empty box" might  
be slightly better

This assumes that there is a "very light" weight available for the default  
font or that a tester knows which faces are available and that using the  
lightest one is fine

==== Gérard Talbot ====

Uses the term "separated borders", would perhaps be better to describe  
expected appearance more directly. Moreover, this test seems to depend on  
the HTML 'rules' attribute mapping to/interacting with CSS rules in a  
certain unspecified way (Opera currently applies the horizontal rules to  
the <tr>s for instance, haven't investigated what makes Fx/IE fail it;  
HTML5 attempts to specify the presentational hints but seems  

==== Gérard Talbot, Hilbrand Edskes ====

It's not at all clear from the wording that the green square should be  
covered by the scrollbar (which basically means that it will look like a  
non-square rectangle)

==== Gérard Talbot, James Hopkins ====

(Probably correct per the current spec, but none of the browsers I tried  
show a square in this case so this might change, see thread starting at  

==== Ian Hickson ====

There are no "links below". Also, the last two sentences should be  
rewritten to not require an understanding of the specification

These are missing a proper pass condition

This test could use a description/an explicit pass condition

==== Microsoft ====

This kind of pass condition is confusing in general (when does the test  
not pass?). In this particular case the "may" is actually also incorrect;  
the assert refers to a note, but the note links to a normative section, so  
overflow should be expected. (Of course this assumes that the span's  
content is wider than 3em when rendered with the default font, probably a  
safe assumption though using Ahem or non-textual content seems better)

See also  
- to an observer not familiar with the spec's terminology, it is not  
obvious that a thick line counts as a "box"

The wording "on top of" is potentially confusing. Maybe use "above"  
instead (also, again the issue of "box" vs e.g. "line" or "stripe")

* "a box" usually implies a rectangular shape, which is not what's being  
expected here
* the "slightly shorter" "half" is not actually supposed to be a half...
* it's not clear in which direction the shortening is to take place
* synthesizing small-caps is just a "may" i.e. optional

Bad description: "if the line of 'Filler Text' and all of the characters  
of the text" should probably be "if all of the characters below this  
sentence are in uppercase" or something similar

Bad description, expects "Filler Text" even though "FillerText" is  

Not having vertical-align:top here might be confusing because the "2"  
digit will be overlapped (and isn't in the sample renderings)

As has already been mentioned  
the tests in this series could use some extra horizontal margins. This one  
in particular is confusing since it calls for a comparison of widths, and  
the full widths of the left and right parts of the outline are clipped

The second X could end up partially overlapping the border (depending on  
e.g. font), can cause confusion on whether the result counts as a "box"

The second instance of "below" is misleading, makes it sound like the  
second square is supposed to be below the first square

Misleading, gives the impression that the widths of cells in column 2 are  
supposed to be shorter than the ones in column 2. Also makes it seem like  
the cells are supposed to be bigger when compared to the border widths

Having just one instance of "Filler Text" in the box would be less unclear  
(there is a space to the left and right of every instance except one,  
after all). Also, apparently the space outside the border doesn't count,  
so a browser that incorrectly right-aligns the text might not fail the  

==== Richard Ishida, Elika J. Etemad ====
An improvement over previous version, but still not quite right (trying to  
use two different formulations at once). Using the word "numbering" might  
confuse some people who would expect to see Latin numerals

Řyvind Stenhaug
Core Norway, Opera Software ASA
Received on Wednesday, 8 September 2010 14:13:54 UTC

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