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

Testcases with ex unit; Microsoft's Chapter_4/numbers-units-019.htm

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Mon, 31 May 2010 18:22:08 -0700
Message-ID: <11638ef2c3dfccb77eec07d1adf0d8b8.squirrel@cp3.shieldhost.com>
To: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Cc: "Arron Eicholz" <arron.eicholz@microsoft.com>
Hello all,

When dealing with ex unit and em unit, browsers do not handle font-size
with fractional pixel the same way. Some will round up when it's over
0.5px and will round down or truncate when below 0.5px. Some other
browsers will first calculate the width and height and then do round up
or truncate after computed width and height have been computed.

Assume a 16px font-size here.

[Addendum: please just load this webpage
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/first-available-font-define-ex-unit.html
]

20ex is rendered as 256px in IE8 and in Chrome 6.0.408.1: 20 times
12.8px = 256px

20ex is rendered as 260px in Firefox 3.6.3 and Konqueror 4.4.3: 20 times
13px (which is 12.8px rounded upward) = 260px. The fractional part is
not multiplied: it is removed (or rather round upward occurs first) and
then the multiplication occurs.

So browsers can have different rendering because they could be applying
rounding up (or truncation) methods either during or after computing the
width and height.


-----------------

One solution for all testcases involving ex units is to only use a
font-size which will always equate to an integer value when using an
integer factor for ex unit.

E.g.: 16px for font-size is bad since 1ex is 12.8px

E.g.: 20px for font-size is good since 1ex is 16px

E.g.: 25px for font-size is good since 1ex is 20px

So, testcases can be created, built in a way that they can elegantly
avoid this fractional font-size issue.

-----------------


Browsers can also have different rounding methods for different units
(em versus ex).

This test

http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_4/numbers-units-019.htm

is pretty amazing by itself because the testcase assumes that 1ex for
Ahem at 16px will be rendered as 0.8em for browsers implementing ex unit
correctly and fetching xHeight fontMetric information.

Firefox 3.6.3 and IE8 create 2 black boxes of 13px wide and 13px tall.
Chrome 6.0.408.1 create 2 black boxes of 12px wide and 12px tall.
Konqueror 4.4.3 create 1 black box (div#test: with 1ex) of 13px wide and
13px tall and the other black box (div#compare: with 0.8em) is 12px wide
and 12px tall.
Opera 10.53, Opera 10.10 and Safari 4.0.5 do not support ex correctly.

---------------


http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_4/numbers-units-019.htm

should be redone so that it avoids this fractional font-size pixel issue.
Also, creating larger and taller boxes would help testers compare the
width and height dimensions.

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 Tuesday, 1 June 2010 01:22:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 September 2010 17:52:02 GMT