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

Created attachment 991 [details]
Testcase

(In reply to comment #1)
> 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.

Good catch.

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

Should this be standardized?  It has some author-visible implications.  To start with, if alpha values are serialized as you suggest, setting and then reading back strokeStyle or fillStyle will give you a different number of digits in different UAs for the alpha, depending on how much internal precision they have.

More than that, presumably it will also be detectable by drawing some non-opaque things on top of each other and measuring the exact color of the result.  If everything gets clamped to 8-bit integers, the rounding will be different from if you use actual floats.

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

Actually, this bug was prompted by the fact that WebKit just changed to more Gecko-like behavior here:

http://trac.webkit.org/changeset/87512

The commit summary said "The number of decimals for alpha values between 0 and 1 is not specified, so match Gecko and Presto by returning the lowest number of decimals needed to represent the number", so my immediate reaction was to get the number of decimal places standardized.  (I don't know why it says "and Presto" -- I get the same results in Opera as you do.)

> setting and then reading back strokeStyle or fillStyle will give you a
> different number of digits in different UAs for the alpha, depending on how
> much internal precision they have.

Yep.  And if you required the same number of digits, then you could still detect the limited internal precision.

If you're asking whether the fact that alpha is stored as an integer in the range 0-255 should be standardized, the answer is "maybe".  Right now the way floats are converted to such integers is not the same across UAs either, last I checked...  Standardizing makes some sense, but we need to be careful to not overconstrain future implementations that may want to allow a wider range of alpha values, assuming anyone would want that.  Worth a mailing list thread.

mass-move component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with comments above.

I tried. Not sure I like the result.

Checked in as WHATWG revision r6411.
Check-in comment: Try to tighten up the definition of how to serialise rgba() in canvas.
http://html5.org/tools/web-apps-tracker?from=6410&to=6411