W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

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

From: Smylers <Smylers@stripey.com>
Date: Tue, 11 Mar 2014 09:28:42 +0000
To: whatwg@lists.whatwg.org
Message-ID: <20140311092842.GA2453@stripey.com>
Ryosuke Niwa writes:

> On Mar 7, 2014, at 3:54 AM, Smylers <Smylers@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.

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.

> > 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
Received on Tuesday, 11 March 2014 09:29:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC