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

[Ryosuke Niwa]

On Mar 7, 2014, at 3:54 AM, Smylers <Smylers at stripey.com> wrote:

> Ryosuke Niwa writes [re-ordered]:
> 
>>> On Feb 19, 2014, at 7:36 AM, "Jukka K. Korpela" <jkorpela at cs.tut.fi>
>>> wrote:
>>> 
>>> 2014-02-19 11:10, Smylers wrote:
>>> 
>>>> Jukka K. Korpela writes:
>>>> 
>>>>> The point is that year numbers aren't really "numbers" in a
>>>>> normal sense, any more than car plate numbers, credit card
>>>>> numbers, product numbers, or social security numbers are. Surely
>>>>> they can be regarded as numbers, but so can car plate numbers
>>>>> and the others.
>>>> 
>>>> Except that years do actually form a sequence, and it's possible
>>>> to perform maths on them; for instances, subtracting one year from
>>>> another yields a duration
>>> 
>>> Mathematically, you are right, but input types aren't based on
>>> general properties of quantities but on practical classification of
>>> input data. All the examples I gave, including year numbers, are
>>> normally input by typing the digits - in contrast with, say, using a
>>> color picker, a data picker, or a slider. And year numbers differ,
>>> as mentioned, from normal numbers as regards to conventional formats
>>> (e.g., 2014 vs. 2,014 or 2'014 or 2 014 or...).
>>> 
>>> So in the input process, a year number is not treated like a number.
>>> It typically appears when asking for year of birth or some other
>>> event (marriage, employment, etc.). The input check is normally
>>> against any non-digit data, the kind of thing we can do with
>>> pattern=...
>>> 
>>> Logically, one might say that since asking for a year is very often
>>> an alternative to asking for more specific data such as month or
>>> day, it should be treated as "date and time input" rather than text
>>> input with restrictions. But I don't see how this would be
>>> practically relevant. What else could <input type=year> be other
>>> than reading some digits? There is the possibility of allowing
>>> two-digit numbers, with an implied century, but if that is
>>> desirable, authors can use <input type=text pattern=\d{4}|\d{2} and
>>> deal with the implied century in their own code.
>> 
>> Let me point out that not every calendar uses simple 2-4 digit numbers
>> to denote years.
>> 
>> The Japanese era name calendar system, for example, requires an era
>> name such as Showa and Heisei associated with each year.
>> 
>> For example, I was born in Gregorian year 1986 but any Japanese
>> government document would say I was born in Showa 61.  My brother was
>> born in 1989 but, again, he must write "Heisei 1" instead on any
>> government form.
>> 
>> There are also even quite few banks and other organizations in Japan
>> that use the era name system for various forms and documents.
> 
> Yes, so for a Japanese organization using the era system,
> <input type=number> would clearly be inappropriate for years.

Yes.

> An international website wanting a could use <input type=text> and let
> users specify the year any way they want — Japanese eras, 2-digit years,
> Roman numerals, whatever. This could only realistically be stored as a
> string, and the only thing the website could do with it is display it
> again; it would be hard to sort by it, or perform restrictions based on
> the year, for instance. In this scenario, there's nothing special about
> the year so far as HTML is concerned.

I don't think that's a good solution because websites probably needed to use that year to do something.

> Or it could force all users to use Gregorian years, and anybody using a
> different system needs to convert their year themselves. At which point
> <input type=number> works just fine.

That's also an inadequate solution as the conversion between two systems isn't easy.
It's not a simple subtraction or addition. Note that iOS natively support Japanese calendar system.

> Or the website could internally store all years using one particular
> system (say the Gregorian one), but allow input in other systems. This
> could be with a free-form text box with interpretation, validation, and
> error-handling on the server side, but that would be a substandard user
> interface. Better would be to use browser-side JavaScript either to
> perform the validation or to provide a year picker which only allows
> selecting valid years; regardless of the interface on this picker — for
> instance, listing Japanese emperors — it could set the value submitted
> with the form to be the equivalent Gregorian year.

This is why type=year would be useful so that UAs could present it in accordance to the user preference.

> Are there many websites currently catering Japanese years by offering
> such an interface? If so, it would make sense to create
> <input type=year> such that browsers can offer this consistently,
> freeing authors from having to develop these for each site.

SMBC, the second largest bank in Japan, has an online account form which asks the date of birth using Japanese calendar system.
They don't provide an option to type that in using the Gregorian calendar at least in the Japanese version of their website.

Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but provides a conversion table from Japanese calendar system:
http://moneykit.net/visitor/account/account14.html

I'll note, however, that both of these use cases are better addressed via type=date.

> However, that still wouldn't solve the problem of <input type=number>
> putting commas in 4-digit page numbers.

Right.  But with if we had type=year, UAs could localize it appropriately for this use case.

- R. Niwa