- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 03 Feb 2011 14:55:28 -0500
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