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

On Tue, Feb 12, 2013 at 9:39 AM, Jukka K. Korpela <jkorpela@cs.tut.fi> wrote:
> 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.

This argument appears to apply equally well to all the date inputs,
and perhaps most of the other new inputs.  I believe it's wrong.

* Most people don't type very fast.  We email-happy people are an
exception.  For most, clicking on things is faster and easier.
* Experience shows that most authors appear to prefer a pair of
dropdowns for selecting month and year, rather than a text input.
Might as well move closer to author expectations.
* Text inputs are permanently subject to the vagaries of whatever
arcane syntax the author happened to want (or didn't want, but
accidentally required when they miswrote their regex) - Do I just type
two numbers with a slash? Or do I use a dash? Or a space?  What if I
use a slash surrounded by spaces? Or do I use the month name? Long or
short name? Two digit or four digit year? - while visual inputs put
your options in front of you and avoid all of that.

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

This same argument keeps getting deployed against type="date".  We'll
see what actually happens.  I expect (and deeply hope) that the ease
of use of the built-ins will win the day, once they're supported on
every browser sites expect their visitors to use.

~TJ

Received on Tuesday, 12 February 2013 17:48:32 UTC