- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 28 Jun 2012 16:07:44 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style@w3.org
On 6/28/12 3:53 PM, Tab Atkins Jr. wrote: > Unfortunately, this is *precisely* the case that that line is intended > to handle. If your number is far enough from 1 to be accurately > represented as a double, there's no need to have special rounding > behavior - it won't be equal to 1 anyway. You're allowing the numbers to be stored with far less precision than a double, so no. > Yeah, I suspect it would require custom string-to-double conversion > routines. That doesn't make me terribly happy, honestly. And it still doesn't handle things like calc(). Ah, well. We'll see how much buggy custom code this causes people to write. ;) > You can at least use the off-the-shelf routine normally, > and then reparse with the custom routine only when you see that the > value is on a boundary. I don't see how that helps much, actually; the boundary common use cases are on a boundary. > I think you have to do similar things already > to correctly parse quirks-mode hashless colors, right? Not really: there you just do a hashtable lookup and parse as a color-like thing on a miss. Importantly, the actual algorithm is defined, whereas the parsing for numbers in the spec here is ... very much not. -Boris
Received on Thursday, 28 June 2012 20:08:14 UTC