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.
Yucca
