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

[Ryosuke Niwa]

> On Mar 11, 2014, at 2:28 AM, Smylers <Smylers at stripey.com> wrote:
> 
> Ryosuke Niwa writes:
> 
>>> On Mar 7, 2014, at 3:54 AM, Smylers <Smylers at stripey.com> wrote:
>>> 
>>> An international website wanting a [year] ... 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.
> 
> It's only useful if there are actually sites which want to do this.
> 
>>> Are there many websites currently catering [for] 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.
> 
> Yes, so they aren't actually demonstrating that <input type=year> would
> be useful.
> 
> Also, both of those seem to be sites intended only for Japanese users.
> As such, a Japanese-specific year selection is sufficient for them; they
> can use <select> for the entire year, or possibly <select> for the era
> then <input type=number> for the year within that era. Such sites
> wouldn't be trying to use <input type=number> for a year in the first
> place, so the unsuitability of it for Japanese years doesn't matter.

It isn't.  Unfortunately, younger generations tend to be more comfortable with the Gregorian calendar while older generations tend to be more comfortable with Japanese era system.

This is why iOS allows users to pick either representation instead of always using either based on locale.

> The need for a widget which offers either Japanese or Gregorian
> interfaces for selecting a year, depending on the user's preference,
> then always submits it in a single defined way to the server, only
> really crops up on an international site which can expect users most
> familiar with each of those calendar systems.

Hence this is not true.

>>> 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.
> 
> Indeed. But if <input type=year> isn't otherwise useful, there may be a
> more generic way of addressing the ‘no commas in 4-digit years’ issue
> which also addresses 4-digit page numbers (and the like).
> 
> Cheers
> 
> Smylers
> -- 
> http://twitter.com/Smylers2