[whatwg] Decimal comma in numeric input

[Jukka K. Korpela]

Henri Sivonen wrote:

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

I see... thanks for the clarification. Yes the description is very general 
and allows user interfaces of many kinds.

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

In general with the new input types, we have the problem that when they are 
not supported but degrade to <input type="text">, the user would need 
instructions on data format, e.g. saying that decimal point be used or that 
a color be specified as #hhhhhh - and these would look stupid when they are 
not needed. But this can probably be handled reasonably using scripts that 
test for the support first. Or maybe it would be more robust, 
transitionally, to include the instructions and <input type="text"> in 
markup, with client-side scripting then trying to set the state to, say, 
"number", and when successful, removing the instructions (or replacing them 
with some different instructions).

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

As far as I can see, such operations _are_ allowed by the current 
formulations. The browser may use various mechanisms for letting the user to 
specify a number, and this includes permissive processing of written 
numbers, as long as the browser ultimately generates a valid number (or 
raises an error).

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

Well that's certainly at least _one_ of the problems. And we might ask 
whether a browser should use the _system_ settings, as they should probably 
be expected to best reflect the user's real preferences.

> Thus, it would be safer to compute the language of the input element,

In practical terms, no. We know that authors generally fail to specify the 
content language or have it mis-specified (typically, as English 
irrespective of the real language) by authoring software.

> treat the language as a locale

Mapping languages to locales is a guessing game, in addition to all the 
other problems involved.

The problems look rather complicated, but at least I now understand the 
issue better.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/