On 20/02/2014 01:34, TAMURA, Kent wrote:
Hi,
The current WebKit/Blink behavior is:
- Accept both of the ASCII digits and localized digits
- Accept both of the standard decimal point '.' and a localized decimal point
That sounds similar to what I've implemented, but users can't mix digits,
decimal or grouping separators from different locales. The entire input must be
consistent. Specifically, input typed in by the user is first processed using
the locale of the element (as defined by the 'lang'/'xml:lang' attributes, if
any). If that fails we retry with the locale of the document (Content-Language
header). If that fails we retry with the locale of the browser. If that fails
then we pass the string off to HTMLInputElement's internals to be set as its
value without "de-localizing" it, where it will be parsed using the HTML 5 rules
for "valid floating-point number" (essentially allowing ASCII digits and decimal
point as the final fallback). (We start with the element and work out looking
for locale information in order to give priority to the locale of the context in
which the input exists.)
For what it's worth I just tried the following in Chrome, and if I type in
"12,34" then increment using the spinner it resets to zero, seeming to indicate
that the "," was rejected. Is that expected?
data:text/html,<input type=number step=0.01 lang=fr>
- Not accept grouping separators and don't show grouping separators
>
We showed grouping separators in the past. But we stopped it because grouping
separators disturb some use cases.
So I've discovered. ;)
We accepted entering grouping separators in the past. But we stopped it because
users had to know their locale correctly. e.g. "1,234" has different meaning in
French locale and English locale if we support grouping separators.
So essentially you assume any separator that is a decimal separator in any
locale is a decimal separator all cases? Even that approach would seem to have
the potential for unexpected results for users; for example, a user types in
"1,234" meaning 1234 but the input takes the value 1.234. Or maybe I misunderstand?
Jonathan
