Bugzilla – Bug 16165
i18n-ISSUE-136: Recognition of number formats in Number state
Last modified: 2014-03-06 23:30:44 UTC
126.96.36.199.13 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
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:
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
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.