W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] Inconsistency between canvas and CSS color serialization

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 03 Feb 2011 14:55:28 -0500
Message-ID: <4D4B0830.3040908@mit.edu>
On 2/3/11 2:39 PM, Tab Atkins Jr. wrote:
> Webkit stores alpha the same way.  I don't believe that's a problem
> here, though - it just means that the<number>  has fairly limited
> precision.  There's nothing requiring browsers to store a particular
> precision for<number>s.  (Whether or not there should be is a
> separate argument.)
>
> The serialized value will round-trip as the same thing, right?  As
> long as that's true, then the convenient fiction that you actually
> store the value you serialize as can be maintained.

Parsing the serialized value will give the same data as was serialized, 
yes.  If it doesn't, that serialization is just broken.

The problem arises because, if you want browsers to actually have 
serializations that are the same, you have to define the "limited 
precision" details.

For example, consider "rgba(0, 0, 0, 0.3)".

When Gecko parses this, the alpha channel will be set to 77, I believe. 
  Then when we go to serialize it, the double-precision floating point 
number 77.0/255.0 is 0.30196078431372547 or so.  And if we output that 
string, authors would, justifiably, lynch us.

So instead we round that ratio to 0.30 and then use the normal C 
routines for converting floating point numbers to decimals with limited 
precision to get the string "0.3".  But the process of producing "0.3" 
instead of "0.30" or "0.302" or "0.30196" is not exactly obvious.  Just 
saying "use your <number>-to-string conversion routine" doesn't cut it, imo.

-Boris
Received on Thursday, 3 February 2011 11:55:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC