W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css3-values] Required minimum precision

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 28 Jun 2012 12:53:21 -0700
Message-ID: <CAAWBYDA8vzG83AkzXzPmO9688poHiUOYKnYXJ=sYE=LF0=jUfQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style@w3.org
On Thu, Jun 28, 2012 at 12:37 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 1)  Where does an absolute value of (2^24)-1 come from?  Since this is
> talking about signed quantities, it's requiring that at least 25 bits be
> used to represent them, which is a slightly odd behavior.  Was this supposed
> to use (2^23)-1 ?

I think it was supposed to be 24 bits, yeah.

> 2)  Implementing the "except that values that are not equal to, but would
> round to, either zero or the boundary of a closed range, are rounded away
> from that value rather than to it." might be rather difficult.  Consider a
> decimal value like 0.99999999999999999999999999999999999999999999 which will
> give you 1.0 when converted to an IEEE double, for example.  The only way I
> see to avoid this becoming 1.0 is for the UA to reinvent the
> string-to-double wheel in a way that allows the rounding behavior described
> in the spec (and in particular, in a way that does not make use of existing
> string-to-double libraries, which do not have any such behavior defined).
>  In this particular case the UA could add a hack like "check the first
> digit", but things get more complicated if we add scientific notation or
> calc().  I'm not quite sure what the best course of action here is....

Unfortunately, this is *precisely* the case that that line is intended
to handle.  If your number is far enough from 1 to be accurately
represented as a double, there's no need to have special rounding
behavior - it won't be equal to 1 anyway.  This is meant to capture
precisely the case where an author wants a value practically identical
to a boundary, but not with whatever discontinuous behavior actually
happens at that boundary, and does so by just spamming digits.  This
is common behavior!

Yeah, I suspect it would require custom string-to-double conversion
routines.  You can at least use the off-the-shelf routine normally,
and then reparse with the custom routine only when you see that the
value is on a boundary.  I think you have to do similar things already
to correctly parse quirks-mode hashless colors, right?

Received on Thursday, 28 June 2012 19:54:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC