[whatwg] Decimal comma in numeric input

[Cameron Heavon-Jones]

On 16/07/2011, at 5:52 AM, Jukka K. Korpela wrote:

> 16.07.2011 00:01, Ian Hickson wrote:
> 
>> Much discussion on this topic happened when we started on this work in
>> 2004 and 2005, I highly recommend perusing the archives around that time.
> 
> Authors and implementors will need to be able to understand the topic without checking discussions archives, so the specs should say at least a little about the issue that the rules for user’s input may be quite different from the rules for the as stored and forwared. And users will be confused anyway, when user interfaces work oddly.

Yes, or if you have the knowledge of these discussions perhaps some additional assistance in locating any specific items would be helpful? 

>> On Thu, 14 Apr 2011, John Tamplin wrote:
>>> 
>>> The entire web application, which includes both client and server-side
>>> code, must have the same idea about what locale the user is using.  If
>>> the app provides a drop-down box or preference setting to choose a
>>> different locale, as most localized apps do, the web browser has to be
>>> using the same locale for any native locale processing it uses.
>>> Otherwise, you run a serious risk of having incorrect data -- if a user
>>> types "10,000" in a field when they think they are using a locale with a
>>> comma as the decimal separator, does the app receive that as 10000 or
>>> 10.000?  If the app is running in en-US because the user requested it or
>>> their system locale isn't supported by the app, and the browser sends
>>> "10.000" as the value because the system locale is "de", then that is a
>>> problem.
>> 
>> Indeed. To solve this, we need help from CSS. That's one of the reasons we
>> created<output>  in HTML.
> 

Concerned about <output>.

> This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. It will probably cause _further_ confusion.
> 
> I’m afraid the new input types for numeric data and for dates and times, even when implemented in browsers, will be of very limited usefulness and will cause more damage than good, unless the localization issues will be properly addressed.
> 
> It is part of the risk that they often _seemingly_ work. For example, an author would use <input type=number> and test the software thoroughly by his own standards, but the standards don’t include testing with the system’s UI language being other than English. So things seem to work until someone tries to put a bid of 10,000 dollars but gets it turned to 10 dollars and loses, or makes a date for 7/4/2012 and gets it interpreted as April 7 when he meant July 4, or vice versa.
> 
> I’m afraid many authors will start using the new types eagerly when browser support comes sufficiently widespread. It looks so much better, cooler, and easier than parsing data yourself or requiring the user to type data in specifically instructed format. But it’s a dangerous illusion.
> 
> -- 
> Yucca, http://www.cs.tut.fi/~jkorpela/


Yes, i agree. I've opened a bug about the handling of i18n by user agents:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13408

In response to the question of how to manage the formatting and encoding of i18n data values, the element's declared or derived lang should be used. the form element also contains a lang attribute and it is this which should be used to encode the data for submission and processing, as the author has declared they expect to accept. ie:

<form lang="en-US">
	<input type="number" lang="fi"/>
	<input type="submit"/>
</form>

This input should parse and format the number in the Finish locale, and the form should encode the number in en-US locale.

Thanks,
Cameron Jones