Clarify length units in CSS

There is a difference in how Gecko and WebKit interpret length units 
(can't check IE, but I guess they have yet another interpretation). The 
CSS spec needs to clarify what the units exactly mean.

Gecko tries to match absolute lengths (in/cm/mm etc) to the real 
physical length by using the display device DPI. When there is 
'width:1cm' in a CSS, Gecko tries to make it physically appear as 1 
centimeter, I can put a ruler to the screen and the element will indeed 
be 1cm wide. But when it comes to 'px' (CSS pixels), Gecko applies a 
logic to make the 1 CSS pixel correspond to an integer number of device 
pixels. So 1 CSS pixel maps to one physical pixel on <143 DPI screens, 
to 2x2 physical pixels on 144-240 DPI screen etc. The logic is described 
on their wiki: http://wiki.mozilla.org/Mozilla2:Units

While I believe this is mostly what the spec intended (absolute units 
are indeed absolute, relative units relative), in some cases it will 
considerably differ. Let's say I'm sitting 28 inches from the screen. In 
that case 96px should be the length of one physical inch. It is indeed 
if I configure Gecko with DPI=N*96 (where N=1,2,3,...), but in all other 
cases 96px will be different from one inch. This is especially well 
visible in the case of DPI=143, when 1in is 50% larger then 96px (1in = 
143 physical pixels, 96px = 96 physical pixels).

WebKit on the other hand does not differ between CSS pixels and absolute 
units. Absolute units have a constant relation to CSS pixels. 1in is 
always exactly 96px, 1cm exactly 96/2.54px etc. This has the effect that 
1in is only one physical inch long when DPI=96. Comments in the code 
indicate that this is intentional, WebKit doesn't see the 'absolute' 
lengths as absolute but relative to a CSS pixel [1]

So what is the correct interpretation of CSS lengths? Is Gecko or WebKit 
right or maybe both wrong?

tom

[1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSHelper.h#L35

Received on Wednesday, 23 July 2008 08:04:57 UTC