W3C home > Mailing lists > Public > www-style@w3.org > February 2004

Re: [css3-values] unit equivalence

From: Mikko Rantalainen <mira@cc.jyu.fi>
Date: Sat, 14 Feb 2004 10:17:17 -0500 (EST)
Message-ID: <402E3C16.3030205@cc.jyu.fi>
To: David Woolley <david@djwhome.demon.co.uk>
Cc: www-style@w3.org

David Woolley / 2004-02-14 15:29:
>>same as 13mm for the same reasons that 1.3 * 10 might not equal
>>13 on a binary computer.
> Doing arithmetic in decimal doesn't seem a great hardship.  If you want
> to speed it up internally, for repeated uses, you can always convert to
> rational binary (13/10).

I don't think the binary presentation is the problem but the fact 
that document authors (rightly?) expect every element that has 
identical 'width' to render identically.

For example, if document author has 10 elements of 1mm each side by 
side followed by another element on the next line that is 10mm (or 
1cm) wide and display's resolution is 8 pixels/cm, how should the 
elements be rendered? If every one of the 10 small elements is 
colored black and white, alternative, should the rendered output 
have different combined width for those 10 elements in contrast to 
the one big element despite the fact that both withds should be the 
same. Or should the big element be not equal to 1cm or 10mm. Or 
should the big element be 1cm and the combined width of small 
elements be 1cm (=8 pixels) and some of the small elements are not 
visible at all, resulting to ugly banding in the color pattern.

The rendering engine might use floating point numbers for all 
positioning and if one "1mm" element ends up rendered zero pixel 
width and another "1mm" element ends up rendered one pixel width, so 
be it. Alternatively, the rendering engine could supersample, but it 
would eat very much CPU power for the dimishing increase in quality.

Received on Monday, 16 February 2004 10:08:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:11 UTC