This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
4.10.7.1.13 Number state http://www.w3.org/TR/html5/number-state.html#number-state "The algorithm to convert a string to a number, given a string input, is as follows: If applying the rules for parsing floating point number values to input results in an error, then return an error; otherwise, return the resulting number." Does this refer to conversion of the text the user inputs into the field, ie. if the user types in 12.345,67 will the rules for parsing floating point number values be applied to that to determine whether or not that is a valid number? Or does this apply only to interpretation of the attribute value or the value passed to the value by the browser after interpretation of the user input? I assumed that this is the case, but it isn't clear. I think a note would be useful, both here and for other states where formats vary around the world, to clarify this and btw to remind browser developers that the normal way of representing numbers differs around the world and they will should expect to have to convert the user input to the expected internal representation (but not change the user's input itself).
This bug was cloned to create bug 17918 as part of operation convergence.
New spec location: http://dev.w3.org/html5/spec/single-page.html#number-state-%28type=number%29
Discussed at the Internationalization WG meeting 2012-11-01: What's really causing the confusion is the phrase "User agents must not allow the user to set the value...". If we understand the intent of the spec correctly, the user doesn't set the value at all; instead, the user types a string in a localized format, it gets interpreted and converted to a value, using algorithms that are not specified in HTML. The conversion algorithms discussed in the spec have nothing to do with user input; they handle text that's part of the HTML source or form submissions. The phrase above contradicts this intent and should be fixed. In addition, the note in the section uses a somewhat extreme example (Persian or Arabic numbers), so it's not obvious that more subtle differences also need to be handled, such as different decimal and grouping separators for German or for India.
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-v2.html Status: Accepted Change Description: https://github.com/w3c/html/commit/3c757c6bddeffabe76bd3e35a2ee77030a49b47e Rationale: Accepted WHATWG resolution
I18N is satisfied by these changes. Thank you. I will note that there is still a "feature gap" in HTML. While the text goes to great lengths to allow user-agents to format input or localize the number input controls, there is still no mechanism to allow the document author to have any control over this format (so that it matches the language or format used in the page). This is actually addressed by bug #16965, so closing this issue as you have addressed our immediate comment.