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

[Qebui Nehebkau]

On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
<nils at dieweltistgarnichtso.net> wrote:
> The number of a calendar year really does not fit into to the number
> model. Year numbering conveys something different than floating point
> numbers or even integers. Standardization of values on ISO years /
> proleptic gregorian calendar could prevent quite a few errors here.

Actually, they seem very clearly to be numbers (an integer offset from
some defined 'zero' value, despite some complexities where the zero
and direction of the offset actually differ between CE and BCE) - they
can be incremented or summed meaningfully, even multiplied (although
not squared, most of the time), and unlike, eg., the mentioned:

On Wed, Feb 19, 2014 at 12:23 AM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> [...] car plate numbers, credit card numbers, product numbers, or
> social security numbers [...]

they can be usefully selected with varying precision (adjacent years
are closely related, but the next credit card number up is completely
different).

On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
<nils at dieweltistgarnichtso.net> wrote:
> Interface-wise, a dialog for <input type=year> without a value might
> focus the current year initially - I would consider that a usability
> boon. Year selection dialogs do already exist:

That's certainly already possible, and would be undesirable often
enough that it is better not to force it. It could make sense as a
default if a value is not supplied, though.

> This rule may not be so useful in general: Digit grouping using dots,
> commas or spaces can be useful when comparing smaller and larger
> numbers. Consider the following grouping of <input type=number>:
>
> [ 210 000 ] [+|-]
> [  19 250 ] [+|-]
> [   1 500 ] [+|-]

To me, this suggests that grouping should eventually be a CSS
property. But, personally, I just don't think the problem justifies a
workaround until we can do that.