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/
