Correctly handling culture

[jsiegmund]

I am using the polyfill in a globalized application. The culture on the serverside changes to whatever the users preference is. The polyfill seems to follow a default culture, which is causing problems.

Example:
I enter "4.6" in a textbox and submit the form.
On the server side (ASP.NET MVC) the value is parsed and my double reads "46". That's because in the Dutch culture settings, the comma is used as a decimal seperator. So the correct value should have been "4,6".

I use the jQuery globalize plugin (https://github.com/jquery/globalize) for formatting based on culture. It would be great if the polyfill would follow that culture.

[jonstipe]

Hmm... The W3C spec requires the use of a period as the decimal separator, but does allow for displaying the value in different formats according to regional preferences. But it still has to be submitted in the standard format, with the period, so this needs to be fixed on the server side. Perhaps this could be done by swapping out the input for a hidden field for submission and a text input for display. But then we don't want to break or override browsers that already have native support for number inputs... hmm...

[jsiegmund]

Right, that neatly sums up the exact same thoughts I had about this. It's understandable the spec describes the way data is sent to the server, but you do want the client and server to be in sync as to what their formatting is.

[jonstipe]

We really don't want to deal with syntactic ambiguities (does "12.345" mean twelve thousand three hundred forty-five, or twelve and three hundred forty-five one-thousandths?), especially in a multi-regional application, so requiring the data to be submitted in a standard format makes sense.

While we could convert formats for display and input, looking at the current native implementations, I'm not sure how to handle that. Chrome and Safari don't let you type a comma in number inputs. This could be problematic.

[mikehaertl]

I think this should be fixed to behave the same like Chrome:

• The input element value and step always use standard format i.e. value="1234.56"
• The value is displayed to the user in a localized format, depending on the locale settings of the browser. I.e. the above is displayed as 1234,56 for German locales.
• The user can enter the format in his local format
• User input gets converted to standard format, i.e. 2345,76 is converted to value="2345.76"

With this in place the server doesn't have to care about any local format at all when rendering/processing the input fields. This is very convenient in Chrome but unfortunately doesn't work in IE.

The decimal separator could probably be autodetected as described here:

http://stackoverflow.com/questions/1074660/with-a-browser-how-do-i-know-which-decimal-separator-does-the-client-use