Microsoft's Chapter_9/positioning-float-002.htm

Hello all,

Testcases involved are:

http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_9/positioning-float-002.htm
(using a width of 15em == 240px)

and

http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-002.htm
(using a width of 2in == 192px)


Robert Stam wrote on jan. 27th 2010
>> 5) ---------
>> chapter_9\positioning-float-002.xht
>>
>> The width of the container is not big enough to fit all the text.
>> Besides that the test is rendered correctly.

Arron Eicholz replied on feb. 1st 2010:
>At the default font size the text is able to fit  correctly. It seems
as >if you are not running at the browser default font setting.

coming from:
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Feb/0003.html


There are at least 4 problems with the 2 versions of the same testcase.

1- As soon as you try the testcase in non-Windows operating systems, the
testcase fails because the font-family in use is not Times New Roman. I
conducted many tests and I definitely side with Robert Stam.

As soon as the span "Filler text" exceeds 61px in width (for
http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-002.htm
), the testcase, as far as the pass/fail condition of the testcase is
involved, automatically fails. The only 2 font-family which did not
exceed 61px are Times New Roman and Impact.

Under Linux KDE
---------------
The span "Filler text" is 86px wide in Firefox 3.5.9 under Linux KDE,
83px in Opera 10.10, 86px in Konqueror 4.4.2 under Linux KDE ("DejaVu
Serif" is the default font-family under Linux KDE's Konqueror 4.x
browser). 192px or 240px are not wide enough if the span "Filler text"
is 83px (or greater) wide. A simple arithmetic calculation will
demonstrate this. 192px is a lot more constraining, restraining, giving
almost no leeway for the testcase, font-family in use.

All 3 "Filler text" plus the 2 blank white spaces easily exceeds the
containing block's specified width of 192px. There is only 9px left for
the 2 white blank spaces.

Under Windows XP with Times New Roman
(Tools/Internet Options.../General tab/Fonts button/Language script:
Latin based/Webpage font), "Filler text" is 61px wide in Firefox 3.6.3,
in Opera 10.51 and in Safari 4.0.5.

In this testcase:
http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-002.htm
(using a width of 2in == 192px)

With Tahoma, it is 70px in IE8 and the 3 "Filler text" plus the 2 blank
white spaces easily exceeds the containing block's specified width of
192px.
With Arial, it is 67px in IE8 and the 3 "Filler text" plus the 2 blank
white spaces easily exceeds the containing block's specified width of
192px.
With Comic Sans MS, it is 81px.
With Courier New, it is 110px.
With Georgia, it is 75px.
With Impact, it is 61px in IE8 and the 3 "Filler text" plus the 2 blank
white spaces do not exceed the containing block's specified width of
192px.
With Microsoft Sans Serif, it is 67px in IE8 and the 3 "Filler text"
plus the 2 blank white spaces easily exceeds the containing block's
specified width of 192px.
With Trebuchet MS, it is 73px.
With Verdana, it is 82px.
With Code2000, it is 82px.

My conclusion is that if the font-family is not Times New Roman or is
not Impact, the testcase (
http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-002.htm
) fails in Windows and fails in IE8 as well.

2- The second problem with the testcase is that the containing block has
a fixed, specified width. One says 2in (192px), the other says 15em
(240px); but even at 240px, it may still fails depending on the
font-family in use. In both cases, such specified widths are
unneedlessly, unnecessarly constraining, restraining to begin with. In
such testcase, the width of the containing block is irrelevant.

A demonstration of this is:
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/CSS21Section95FloatExample.html
which comes from the CSS 2.1 spec itself:
http://www.w3.org/TR/CSS21/visuren.html#float-position

Without a defined, fixed width, the testcase would not fail because of
font-family in use.

3- The testcase does not distinguish visually any of the 3 "Filler
text". So, if a browser would fail the provided pass/fail condition, it
could still nevertheless pass the testcase-ed, targeted behavior of the
spec. And that is the case with Linux browsers using a font-family with
wider glyphs. None of the 3 "Filler text" is identifiable in the
testcase, say, by color or background-color or some other visual cues.

4- The testcase passes - always - if CSS support is disabled or if the
browser does not support CSS. Now, that's a sign that such testcase has
a limited relevance, reliability.


For all these reasons, the testcases

http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_9/positioning-float-002.htm
(using a width of 15em == 240px)

and

http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-002.htm
(using a width of 2in == 192px)

should be reviewed again, corrected, adjusted.

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

CSS 2.1 test suite (alpha 2; March 16th 2010):
http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/toc.html

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

Received on Monday, 26 April 2010 19:15:38 UTC