[whatwg] Decimal comma in numeric input

[Jukka K. Korpela]

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.

> 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.

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/