W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

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

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Thu, 31 Jan 2013 16:19:30 +0200
Message-ID: <510A7D72.9060007@cs.tut.fi>
To: whatwg@lists.whatwg.org
2013-01-31 14:20, Bruce Lawson wrote:

> Others have commented on use-cases for collecting month, eg credit card
> expiries.

I have seen forms that prompt for year in month to specify start of 
employment (apparently when the exact date is not interesting) or a 
month to use when searching for cheapest flights to somewhere, 
apparently assuming that the customer is flexible with dates. Or you 
could have a month selection in a calendar application, or budget 
application.

There are several use cases. It might be argued that they are 
considerably less common than selecting a day,

The main problem is different, and shared with other date and time 
fields: do authors really want each visitor to see whatever widget his 
browser is showing? In the ideal world, maybe. There is great potential 
in principle, since the widget could be selected, by the user or someone 
helping him, so that it meets the user’s personal needs and preferences. 
It could also be argued that in the long, it greatly improves usability 
if different sites and applications use methods based on such widgets, 
so that the user can routinely use them, instead of wondering why this 
widget does not work the way he would expect from past experience with 
similar widgets. But is this going to happen? Why would 
authors/designers/managers favor some “standard widgets”?

> The use-case for an input type I imagine is that a browser can have a
> select-like UI (Jan, Feb, March, April ...) which, in a French language
> browser becomes "Janvier, Fevrier, Mars, Avril .. " (or even Vendémiaire
> to Fructidor for FRC fans).

Right. And this probably becomes a nuisance if you need to select 
December 1952, because the widgets have typically been designed so that 
you need to click on something to get one year forward or backward. The 
other problem is that in non-supporting browsers, or in browsers that 
implement <input type=month> in a very simple manner (textbox, user 
input is taken as such, just checked for correctness), the user needs to 
type e.g. 1952-12, which is fast and simple – as soon as you know what 
is expected from you.

Yucca
Received on Thursday, 31 January 2013 14:20:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 January 2013 14:20:07 GMT