Re: CSS 2.1 test suite feedback: test feedback

> On Oct 3, 2010, at 12:19 pm, Gérard Talbot wrote:
>


>> http://test.csswg.org/suites/css2.1/20101001/html4/units-002.htm
>>
>> http://test.csswg.org/suites/css2.1/20101001/html4/units-003.htm
>>
>> units-002.htm:
>> I disagree. The testcase absolutely needs to check the vertical
>> alignment of bottom and top of all 3 rectangles: the 2 "É" and the img
>> will (should!) be all using the ascent space and will (should!) be
>> "sitting" on the baseline: they will not be using the descent space.
>> 0.8
>> mult 250px = height of image.
>>
>> Same thing for units-003.htm and with descent space (below baseline).
>>
>> Those units-002 and units-003 really must be comparing ascent space
>> and
>> descent space: so vertical alignment of bottom and top of all 3
>> rectangles must be compared and are the decisive goals/purposes of
>> those
>> testcases.
>
> So in Safari, the orange box is taller

I noticed a recent change in Safari's way of handling ex and ahem. I
swear Safari 4 was passing all my ex testcases and was displaying 1ex
for ahem font as 0.8em. Chrome 6.0.472.63 passes both units-002.htm and
units-003.htm testcases.

>, but the bottoms of the boxes are
> aligned.

So, that part of those 2 testcases is passed then.

> If the text said "they must be the same height, and aligned", this would
> be
> easier to judge than "exactly aligned with their top and bottom" (since
> you can't
> be exactly aligned at top and bottom and not be the same height).

The exact height of all 3 rectangles are a consequences of
implementation 1ex == 0.8em for ahem. Suddenly, recently, Safari 5 (can
not remember exactly which version but I reported my finding wrt Safari
5 in this mailing list) stopped implementing 1ex as 0.8em for ahem and
started to do 1ex == 0.5em for ahem font.

The flush vertical alignment at the bottom is a consequences of
implementing vertical-align correctly. É has an ascent; p has a descent.
É must be above the baseline while p must go below the baseline.



>>> active-selector-002: confusing
>>> active-selector-004: ambiguous
>>
>> http://test.csswg.org/suites/css2.1/20101001/html4/active-selector-004.htm
>>
>> My neighbour would rightfully, I think, ask me "What is activating a
>> text?" and/or "How do you activate a text?".
>
> Agreed; the text should say "activate (for example, click and hold)" or
> similar.

That's a good suggestion.


>>> cascade-precedence-001: ambiguous: vertical or horizontal center?
>>
>> Simon, I have to rethink anyway all those cascade-precedence-00*
>> because
>> webkit browsers use "text-align: auto" and mozilla browsers use
>> "-moz-center-or-inherit" (and not text-align).
>
> Does that make the tests invalid?

Yes and no. Those testcases are correct as far as code, building logic,
testcase goals, etc. are involved. What is not expected, not predicted
in those testcases is that user agents may be using/relying on something
else than
th {text-align: center}
in their respective user agent stylesheet for centering table header cells.

CSS 2.1 provides a possible example of what I could do:

div {font-style: normal;}

<div><em>This text should be oblique, slanted</em></div>

"for visual browsers, the EM element in HTML is presented using an
italic font)"
http://www.w3.org/TR/CSS21/cascade.html#cascade

but then again, there is no normative requirements for user agent
stylesheets in CSS 2.1, even for EM element.

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

CSS 2.1 test suite (RC2; October 1st 2010):
http://test.csswg.org/suites/css2.1/20101001/html4/toc.html

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

Received on Sunday, 3 October 2010 20:42:12 UTC