[whatwg] Decimal comma in numeric input
vetesnik at mrmil.cz
Thu Apr 14 03:06:02 PDT 2011
Dne Thu, 14 Apr 2011 11:40:12 +0200 Henri Sivonen <hsivonen at iki.fi>
> 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
>> 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
>> 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
>> processing: an error shall be returned, and the value sanitization
>> shall set the value to the empty string; ref.:
>> 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
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...
More information about the whatwg