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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12824

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

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

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