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

[Nils Dagsson Moskopp]

Qebui Nehebkau <qebui.nehebkau+whatwg at gmail.com> writes:

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

I consider year-era-constructs as names for a duration of time. We can
have different names than refer to the same duration of time, like “2014
CE” and “2557 BE” and “ROC 103”. The fact that most of these calendar
systems use a neutral element (era) and a successor function does not
detract from that: Many contemporary calendar systems also have the
concept of month numbering (“february is the second month”) – still, in
the interest of localization, the ISO date string value “2014-02” in
<input type=month> might be rendered as e.g. “Februar 2014” (German).

Btw, a meaningful type system should probably prevent you from summing
year numbers. “2012 CE + 2013 CE + 2014 CE” should not result in “6039
CE”, but a duration of time from 2012 CE to 2014 CE.

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

I do not think the specification should “force” any interface. It is
just that if I were asked to implement a year picker, it would both a)
focus on the current year if no value was given and b) display the year
number (name) according to the current locale settings.

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

I sincerely hope grouping does not become a CSS property, as it is
locale dependent. Authors can (and will) ruin this for users not in
their locale.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>