This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
After a discussion with Boris on IRC, it seems like the current way of parsing floating point numbers in HTML (see URL) do not match what javascript does. This really should match. One of the issue Boris mentioned is that HTML specs do not allow a leading '+'. According to him, other issues might exist.
For example, "1.e5" is parsed as 1.0000 by the current HTML5 algorithm, but 100000.0000 by JS and general string-to-float libraries.
And at step 12, sub-step 2, we have to go to /conversion/ if the character at /position/ isn't in [0-9]. It seems like a mistake given that we are skipping step 13. That would make these two strings being parsed differently: "1.e5" and "1.0e5". The former would be converted to the number "1" and the later would be parsed to the number "100000".
(In reply to comment #2) > And at step 12, sub-step 2, we have to go to /conversion/ if the character at > /position/ isn't in [0-9]. It seems like a mistake given that we are skipping > step 13. > That would make these two strings being parsed differently: "1.e5" and "1.0e5". > The former would be converted to the number "1" and the later would be parsed > to the number "100000". This was conflicting with Boris' comment but I still posted it given that it has more details about where the issue is.
Why doesn't HTML just defer to ES here?
*** Bug 12296 has been marked as a duplicate of this bug. ***
Bug 12296 is actually not a duplicate, but it's related: parsing integers also doesn't match ES.
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: We can't use the exact parseFloat() algorithm since that supports things like "Infinity". I've fixed the algorithm to support the syntax ES supports, though. These mistakes were unintentional.
Checked in as WHATWG revision r6084. Check-in comment: Fix a couple of parser bugs that made valid ES floating point numbers not get parsed to the same meaning in HTML attributes http://html5.org/tools/web-apps-tracker?from=6083&to=6084
If the only problem is things like Infinity, why don't you invoke ParseFloat from ES and then explicitly handle the Infinity/-Infinity/NaN cases? That way you don't risk any unexpected differences. The step "Let rounded-value be the number in S that is closest to value, selecting the number with an even significand if there are two equally close values" in the current algorithm is particularly unreasonable. That's not algorithmic at all. There's no obvious way to implement it, unless maybe you're a lot more familiar with floating-point numbers than I am. In particular, my inability to implement the spec's algorithm makes it hard to rigorously test it. I ran into this when doing the reflection tests. If the spec was based on parseFloat(), I could at least test that the parseFloat() implementation matches the HTML floating-point parsing implementation, in addition to testing various specific values to make sure they're correct.
Um, the text you're complaining about is almost verbatim from the ES spec!
Okay, fine, that particular line is. There's still no call to respecify the whole thing in different words, *especially* if you intend the results to be the same. It just makes life harder for implementers, authors, and testers.
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: Rejected Change Description: no spec change Rationale: Much as with integers, I disagree that the ES spec's algorithm is what we actually want here. It's not stable on the long term, and if the algorithm isn't truly identical, I think the benefits of deferring to another spec with a delta are much oversold.
As with bug 12296, I disagree. Browsers have to support the ES spec anyway, and it's a waste of everyone's time to have a second algorithm that's extremely similar but not quite the same. But I doubt I'll convince you.
Oh, whoops, I'm not the filer here, so I shouldn't mark it CLOSED or Disagree.
mass-moved component to LC1