W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Decimal comma in numeric input

From: Oldřich Vetešník <vetesnik@mrmil.cz>
Date: Thu, 14 Apr 2011 12:06:02 +0200
Message-ID: <op.vtxacccbo84pey@pc36.virtualebrana>
Dne Thu, 14 Apr 2011 11:40:12 +0200 Henri Sivonen <hsivonen at iki.fi>  
napsal(a):

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

I am afraid that if the decimal separator (in rendering) doesn't behave  
the way people expect it to, it will mean web developers will have to deal  
with clients saying "We wan't to be able to enter a comma." The "dealing"  
might mean not using <input type="number"> at all, which is something we  
might not want...

Ollie
Received on Thursday, 14 April 2011 03:06:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT