[whatwg] Please consider adding a couple more datetime <input> types - type="year" and type="month-day"

[Tantek Çelik]

On Sun, Aug 8, 2010 at 4:44 PM, Kit Grose <kit at iqmultimedia.com.au> wrote:
> How is a "year" input any different from a four-digit input type="number" field?
...
> I'm not sure what sort of additional validation you would need in a year field that you couldn't accomplish with "number", unless "year" is just an alias for "number" with a size of 4.

It's not "just" an alias.

It is very similar, however different in that:
* it has the *semantic* of being a year, which is a special type of
number (potentially more than four digits if you subscribe to "Long
Now"[1] methodology, or fewer than four as Andy noted).
* this semantic gives browsers the opportunity to present a "year"
picker control that is styled in appearance consistently with other
datetime inputs (rather than just a number input)
* this semantic gives robots the opportunity to understand that a form
takes time based information rather than just a number (if for example
robots perform time based form submissions/searches on our behalf at
some point)


> Jakob Nielsen's testing has shown that forcing users to enter dates using drop-down menus (or any other non-textual input) is a mistake: http://www.useit.com/alertbox/20001112.html

This feedback is perhaps relevant to/if a browser (that) implements a
drop-down menu control for dates - nothing in this proposal suggests a
drop-down menu.


> I do see some value in the day & month combined input, since it can impose simple rules like when to permit 30th/31st dates. I'm not entirely sure how such an input would appear in visual UAs though;

Right - the specific visual appearance is up to UA designers.
Currently there is quite a bit of variance/experimentation of what
datetime inputs look like from browser to browser (e.g. Safari,
Opera), or even across different versions (Opera 10.55 vs 10.6) or
even across devices (Mobile Safari vs. Safari).


> a calendar would be inappropriate since the days of the week are tied to the year, and the presence or otherwise of the 29th of February in such a control would be difficult to present.

Again, good feedback to give a UA if it happens to do that.  Nothing
in the proposal requires what you suggest.


> Is it really an issue for this field to exist independently of the month and day types just for things like validating the length of the months?

In my opinion the use cases for it are just as (if not more) common as
are (would be) for input type="week", e.g. birthdays, new holidays.

Thanks for the questions, I've added them to a new FAQ section on the proposal:

http://wiki.whatwg.org/wiki/Input_element#new_datetime_input_FAQ

Tantek

[1] http://www.longnow.org/


> On 09/08/2010, at 9:20 AM, Tantek Çelik wrote:
>
>> Summary: the 6 new datetime <input> types are quite useful for a
>> variety of use-cases but could use 2 more that fit in with the current
>> set.
>>
>> In addition to current new absolute types of "date", "week", "month",
>> it makes sense to add type="year" as well for choosing a year value.
>>
>> And in addition to the current new relative type of "time", it makes
>> sense to add type="month-day" as well (for a inputting a month and a
>> day without a year, e.g. for a birthday without birth year, or for
>> entering custom annual holidays).
>>
>> More details, use-cases, research here:
>>
>> http://wiki.whatwg.org/wiki/Input_element#new_date_time_inputs
>>
>> I encourage fellow web authors and browser implementers to add their
>> opinions/comments to that wiki page section.
>>
>> Thanks!
>>
>> Tantek
>>
>> --
>> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
>
>



-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5