12220 2011-03-02 17:04:07 +0000 Make sure rules for parsing a float are the same in HTML and in Javascript specifications 2011-08-22 20:57:35 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED WONTFIX http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values P2 normal --- 13689 11887 1 mounir ian ayg bugs bzbarsky contributor ian mike Ms2ger public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 46177 0 mounir 2011-03-02 17:04:07 +0000 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. 46180 1 bzbarsky 2011-03-02 17:25:59 +0000 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. 46181 2 mounir 2011-03-02 17:28:42 +0000 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". 46182 3 mounir 2011-03-02 17:29:46 +0000 (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. 46206 4 ayg 2011-03-03 00:21:05 +0000 Why doesn't HTML just defer to ES here? 46681 5 ayg 2011-03-14 14:15:17 +0000 *** Bug 12296 has been marked as a duplicate of this bug. *** 46683 6 ayg 2011-03-14 14:17:03 +0000 Bug 12296 is actually not a duplicate, but it's related: parsing integers also doesn't match ES. 48102 7 ian 2011-05-05 21:16:00 +0000 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. 48103 8 contributor 2011-05-05 21:16:50 +0000 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 48192 9 ayg 2011-05-06 17:14:24 +0000 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. 48231 10 ian 2011-05-06 20:17:43 +0000 Um, the text you're complaining about is almost verbatim from the ES spec! 48241 11 ayg 2011-05-06 20:42:08 +0000 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. 52120 12 ian 2011-08-03 06:50:21 +0000 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. 52202 13 ayg 2011-08-03 17:18:40 +0000 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. 52205 14 ayg 2011-08-03 17:32:22 +0000 Oh, whoops, I'm not the filer here, so I shouldn't mark it CLOSED or Disagree. 52410 15 mike 2011-08-04 05:01:12 +0000 mass-moved component to LC1