Re: [css3-values] unit equivalence

> [Original Message]
> From: David Woolley <david@djwhome.demon.co.uk>
>
> > 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
> > unit difference, a difference which is at most one pixel, and may be
> > less.
>
> As Mikko has pointed out, the worst case is 1 pixel for each element, 
> not one pixel cumulative.

Yes, 1 pixel per element.  I wasn't saying otherwise.  However,
that problem is not solved by  mandating unit equivalence.
All unit equivalence does is define a specific method of generating
the round offs that lead to this problem, but unless CSS is going
to specify a specific internal unit that all UAs must use, it can't
guarantee that two different UAs will be pixel equivalent.  Requiring
such an internal unit is not a good idea in my opinion.  Even if CSS
were to adopt such a Draconian solution, it still wouldn't be able to
guarantee that for example a table of n columns, each of which
was defined to have a width of w, and with no border or padding
to complicate things, would always use the same number of pixels
as an element defined as having a width of nw.

At best, such a solution would guarantee that all UAs would differ
from pixel perfection in the same way when they did differ,
not that they would not differ for some values of n and w.

On the other hand, an ability that would enable one to say:

Let [x] = the value rounded to the nearest internal unit.
Make the width of Column 1, [x]
Make the width of Column k, [kx] - [(k-1)x].

And get that the sum of the widths of those n columns would be
[nx], every time.This case can of course be generalized so
that the columns would not all have the same width, but
expressing it in plain text would get very tedious.

This would solve the pixel problem that was pointed out,
and does not require that CSS mandate unit equivalence
to achieve a solution.

Received on Saturday, 14 February 2004 19:57:07 UTC