- From: Smylers <Smylers@stripey.com>
- Date: Tue, 11 Mar 2014 09:28:42 +0000
- To: whatwg@lists.whatwg.org
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