[whatwg] Why do we have <input type='month'> and <input type='week'>?
Jukka K. Korpela
jkorpela at cs.tut.fi
Tue Feb 12 09:39:50 PST 2013
2013-02-12 19:26, Tab Atkins Jr. wrote:
> The fact that authors today have a random assortment of displays for
> the exact same feature (credit card expirys) is something that would
> be great to fix, not bemoan as a loss to the world. ^_^
Well, maybe, from some point of view, but is there really something to
be fixed, and is it probable that <input type=month> would fix it?
I have seen many input widgets for such data and used them a lot in test
purchases. In general, the more advanced they try to be, the more
annoying they get. I can type "03/15", or whatever reads in the card,
rather fast. But if I have to pick things up from dropdowns or click on
something in a calendar picker, I surely hope I won't need to do this a
dozen more times.
What are the odds that browser vendors will implement <input type=month>
in a simple manner that allows fast typing as one input method? Rather
small I think.
This would make the most obvious, and perhaps the most common, use for
<input type=month> a case *against* it. Credit card expiry month is
best handled with a text input field, with suitable checks on the input
string. There may be *other* cases where graphic widgets are good when
selecting a month, but authors can use libraries for such purpose, and I
don't see any particular reason why this should be standardized across
pages but not across browsers.
Even if <input type=month> became widely supported, many, probably most,
authors will keep using libraries or their own code, because they get
consistent look and feel and functionality across browsers. Some authors
would be misled into using <input type=month> for any month input
because that's "logical" or "semantic" (as it is in a sense), but this
will create questionable user experience in many common cases.
More information about the whatwg