Bug 16165 - i18n-ISSUE-136: Recognition of number formats in Number state
i18n-ISSUE-136: Recognition of number formats in Number state
Status: CLOSED FIXED
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
PC All
: P3 normal
: ---
Assigned To: Silvia Pfeiffer
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-29 19:51 UTC by Richard Ishida
Modified: 2014-03-06 23:30 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Ishida 2012-02-29 19:51:05 UTC
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).
Comment 1 contributor 2012-07-18 07:17:02 UTC
This bug was cloned to create bug 17918 as part of operation convergence.
Comment 2 Norbert Lindenberg 2012-11-20 01:12:52 UTC
New spec location:
http://dev.w3.org/html5/spec/single-page.html#number-state-%28type=number%29
Comment 3 Norbert Lindenberg 2012-11-20 01:34:07 UTC
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.
Comment 4 Silvia Pfeiffer 2013-02-15 21:21:49 UTC
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
Comment 5 Addison Phillips 2014-03-06 23:30:44 UTC
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.