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

Re: Proposed improvements to c414-flt-ln-002

From: Øyvind Stenhaug <oyvinds@opera.com>
Date: Fri, 08 Oct 2010 14:00:43 +0200
To: Gérard Talbot <css21testsuite@gtalbot.org>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>, "Geoffrey Sneddon" <gsneddon@opera.com>
Message-ID: <op.vj9abhmpbunlto@oyvinds-desktop>
On Thu, 07 Oct 2010 21:52:26 +0200, Gérard Talbot  
<css21testsuite@gtalbot.org> wrote:

>> If the big green box is aligned to the line below the small green box,
>> and
>> the small green box has a bunch of "filler text" to its left that fills
>> a
>> bigger space than the green box would need, does that mean it's a fail
>> or
>> not?
> No, it does not (and should not) mean that it is a fail in such case.

Per the spec that depends on the location of the green box, as detailed  
below. Anyway, my point was that this is not at all obvious to a tester  
without knowledge of the spec.

>> Actually, this depends on where the small green box is located. If
>> moving the large box up would cause the small box to be pushed to the
>> next
>> line when the filler text is pushed to the right, it's not a fail.
>> Otherwise it is.
> So, it is no longer an interactive testcase.

Right (the idea was that it would be multiple non-interactive cases). The  
pass condition of an interactive test would be a lot more complicated, I  

> Because it is now entirely static and semi-rigid (enclosing div width is
> 30em), then it loses a lot of the aspects (resizing dimensions, resizing
> of text size impacting on content dimensions) of the original testcase.
> That is what I was trying to preserve.

The original test doesn't say anything about resizing, it just randomly  
triggers some particular case depending on what the viewport size happens  
to be.

> There are already quite a few testcases on vertical alignment of floats
> in static testcase in the test suite.

OK. I don't have an overview of the test coverage. If these particular  
static cases are already covered then it makes sense to make this test  

> It is not clear in my mind what ahem font does more or does better than
> what a normal serif font was doing in my version or could do when used
> in your version.

A generic serif font would make it difficult or impossible to trigger a  
particular configuration, so an accurate pass condition would have to be  
really complicated to account for all possible valid and invalid  

Øyvind Stenhaug
Core Norway, Opera Software ASA
Received on Friday, 8 October 2010 11:59:26 UTC

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