W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

[Bug 12824] This doesn't say how to serialize non-zero alpha values: how many digits should be used? The correct answer is the minimum number necessary so that the resulting string evaluates to the same floating-point number as you started with.

From: <bugzilla@jessica.w3.org>
Date: Tue, 31 May 2011 02:09:57 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QREP7-0000oR-UD@jessica.w3.org>

Boris Zbarsky <bzbarsky@mit.edu> changed:

           What    |Removed                     |Added
                 CC|                            |bzbarsky@mit.edu

--- Comment #1 from Boris Zbarsky <bzbarsky@mit.edu> 2011-05-31 02:09:56 UTC ---
Actually, the correct answer may be to use however many are needed to ensure
that your round-trip back to the same value you have now if you parse the

For example, consider a UA that stores alpha internally as an integer in the
range [0, 255] (a very common thing to do; Presto, WebKit nightly, and Gecko
all do it).  It most certainly cannot produce the original floating-point
number when asked.  What it _can_ produce is a floating-point number which when
parsed and converted to an integer in that range will produce the integer you
start with.  In practice that means either 2 or 3 digits of precision.

I agree that this should be specified.

I'll attach a simple testcase that tests what browsers do right now for alpha
values of 0 to 1 in steps of 0.001; it shows that Presto, Gecko, and WebKit all
step up their serialized value only once every 0.004 or so, which means they're
storing 250-ish distinct values, as I said above.

Note that of the three Gecko is the only one that even tries to make the
serialized value look "nice" (in the sense of using the smallest number of
digits that will round-trip to the same integer; this means that 0.1 ends up
serialized as "0.1" and not "0.09804" (Chrome) or "0.10196" (Presto and

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 31 May 2011 02:09:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:50 UTC