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

Ian Hickson ian at hixie.ch
Tue Dec 7 15:56:25 PST 2010

On Tue, 31 Aug 2010, Christoph Päper wrote:
> I’m not sure, but I think it’s at your end that character encodings get 
> garbled.

Yes, I am unfortunately using an encoding-impaired MUA.

> Ian Hickson:
> > On Tue, 24 Aug 2010, Christoph Päper wrote:
> >> 
> >> - Input two-digit year, transmit four-digit year.
> > 
> > Do sites really want to support two-digit years?
> Not sites, year input widgets!

I mean, are there authors who are doing this now? As far as I can tell, 
the Web's year input widgets today all use four digits and are none the 
worse for it.

> >> - Input year name or number in a different system (including 
> >> “AD”/“BC”/“CE”, emperor eras etc.), transmit proleptic Gregorian year 
> >> number.
> > 
> > Non-contemporary dates aren't in the most common 80% of use cases,
> “2010 AD” is contemporary (although too verbose for most use cases). 
> It’s just about what the user enters and sees, not about what gets to the server.

I don't think entering "2010 AD" is in the most common 80% of use cases 
either. In fact I don't know any sites that do that today but don't 
also support non-contemporary dates.

> My sole point was that “year” is not always conceptually a 4-digit 
> number for the users, but it should always be when it arrives at the 
> server. This includes the Japanese use case.

I agree that the Japanese year issue is one we should examine, but I think 
we should examine it once we've proved that the current proposals are 
solid, much like with <time>.

> > Are any browsers interested in implementing such a feature?
> The OS I’m using at home supports 12 kinds of calendars, other popular 
> OSes probably have similar i18n support. Why shouldn’t browsers?

The motivations of browser vendors and of OS vendors aren't always the 

On Tue, 31 Aug 2010, Martin Janecke wrote:
> Am 31.08.10 03:36, schrieb Ian Hickson:
> > On Tue, 24 Aug 2010, Martin Janecke wrote:
> > > 
> > > Future browser could offer a calendar tool to fill input fields that 
> > > have a date semantic. While this would be appropriate, it would not 
> > > be appropriate to offer a calendar tool for other integer data e.g. 
> > > an input field that asks the user for his monthly income in USD.
> > 
> > Why would you want a calendar tool for a year?
> Actually, I'd be fine with typing a whole YYYY-MM-DDThh:mm:ssTZD 
> date/time into an ordinary text input field.
> But as it seems HTML will have date and time input fields. Taking this 
> into account I'd be confused to experience different behavior for 
> different date fields in the same form, i.e. sometimes being able to use 
> a calendar tool and sometimes not being able to use it.

I do not buy that people will get confused because they can't see a 
calendar to pick a year but can to pick a day.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list