[whatwg] Decimal comma in numeric input

[Henri Sivonen]

On Thu, 2011-04-14 at 12:05 +0300, Jukka K. Korpela wrote:
> I was surprised at seeing that the Finnish-language version of Google Chrome 
> 11 beta accepts a number with a comma, such as "4,2", in <input 
> type="number">. It silently converts the comma to a full stop, "4.2".
> 
> This looked like a useful feature at first sight, as decimal comma is 
> standard in Finnish as in most human languages. But this seems to violate 
> the rules, since <input type="number"> is defined as allowing a "valid 
> floating point number" (the definition of which clearly allows FULL STOP as 
> the only decimal separator) only and, moreover, there is prescribed error 
> processing: an error shall be returned, and the value sanitization algorithm 
> shall set the value to the empty string; ref.:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
> 
> So the Google Chrome implementation is in error here, right?

No. The the requirements you cite apply to what goes over the wire and
appears in the DOM. The browser may provide a comma-base UI for
manipulating the value that is stored and transfered using a period.

It does mean that the degradation story in browsers that don't support
the numeric form input types is worse for locales that don't use the
period as the decimal separator.

> On the other hand, would it be useful to _allow_ localization so that a 
> browser _may_ interpret a comma as a decimal separator?

No. Having "may" in processing rules is a recipe for
non-interoperability.

> Google Chrome seems to take the localization so far that if I specify 
> value="4.2", it gets displayed as "4,2", and if I type "5.5" in the field, 
> it gets automatically converted to "5,5" in the visible rendering - though 
> in DOM and in the submitted form data, it's "5.5".

That seems reasonable when the field is in a comma-enabled mode.

> Things get risky, because if the user then enters "1.500" (which corresponds 
> to the old way of writing one thousand five hundred in digits in Finnish, a 
> notation still used to some extent and still official in some other 
> languages) in <input type="number"> field, it gets accepted and sent as 
> "1.500" (one and a half), if the value restrictions allow it - though the 
> visual rendering is automatically changed to "1,5".

I think the main problem is triggering the decimal separator mode (or
the order of numeric day and month for that matter) on the UI locale
rather than the locale of the page, because a normal user won't know if
a page has browser-supplied features or site author-supplied features.
It's quite reasonable for a Finnish user to expect a U.S. site to
require input using the U.S. conventions when all the surrounding text
is in American English.

Thus, it would be safer to compute the language of the input element,
treat the language as a locale  and use that to trigger the
comma-enabled mode. Unfortunately, this requires the browser to have an
exhaustive list of locales and their decimal separators. Fortunately,
relative comprehensive data is available as part of operating systems
and as part of liberally-licensed Free Software such as ICU these days.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/