Re: [whatwg] Why do we have <input type='month'> and <input type='week'>?

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

Received on Tuesday, 12 February 2013 17:40:15 UTC