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

Re: [css3-values] unit equivalence (was: [CSS21] response to issue 140b)

From: Ernest Cline <ernestcline@mindspring.com>
Date: Sat, 14 Feb 2004 10:16:26 -0500
Message-ID: <410-22004261415162646@mindspring.com>
To: "David Woolley" <david@djwhome.demon.co.uk>, www-style@w3.org

> [Original Message]
> From: David Woolley <david@djwhome.demon.co.uk>
> > Actually, I would have to say that in the context of CSS, it would
> > be best to not require that 1cm = 10mm exactly.  Here's why:
> I think that CSS should favour the user in this context.  Most users
> won't have read the specification or appreciated the subtlety, so
> will be upset if some implementations cause two constructs to be
> a pixel off because one was spaced as a large number of mm widths
> and the other one as a single cm width.

Heck, even if identical units are used, round-off error can still cause
problems. 10mm + 10mm might not equal 20mm.  Round-off error
is a fact of life for computers.  What would help is having some way
of doing simple arithmetic with units so that an author could specify
a value of say 20mm-10mm so that he could be guaranteed that 
10mm + (20mm-10mm) = 20 mm even with rounding that the UA
might do. (I am presuming that the UA will not be having to work
with quantities so large as to make overflow a consideration.)

> More of a problem here is that the individual mm widths probably
> get rounded to pixel boundaries, which will encourage people to
> use pixel widths, when these are the worst units to use from 
> media independence and accessibility points of view.

It is a problem, but a very very small problem. Most of the time, the net
effect of this will be no effect, and at worst it will be a one internal
difference, a difference which is at most one pixel, and may be less.

> > 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).

There is a considerable difference in speed of computation between
binary and decimal, even on those machines that support a native
decimal format.  Division is also slower than multiplication.  For a visual
UA that supports all CSS 2.1 visual properties, that's at least 35 possible
<length> values that need to be dealt with per element.  Even for a fast
desktop computer, requiring exact decimal computation is going to
impose a noticeable performance penalty, and doing so won't fix the
problem of positions occasionally differing by a pixel between two
conforming implementations.
Received on Saturday, 14 February 2004 10:16:28 UTC

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