[whatwg] <input type=number> for year input

[Jonathan Watt]

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