How is a "year" input any different from a four-digit input type="number" field? 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 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.
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; 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. 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? —Kit 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
