Input element

This article is a stub. You can help the whatwg.org wiki by expanding it.

Research, data, use cases, issues, and enhancements related to the HTML5 input element.

new date time inputs

The current new date time inputs cover a number of interesting and broad use-cases of various levels of granularity for absolute date and time input types:

* month          (specific year, month)
* week           (specific year, week (implied month(s)))
* date           (specific year, month, day)
* datetime       (specific year, month, day, time)
* datetime-local (specific year, month, day, time, timezone)

As well as one floating time input:

* time           (specific time, but no specific day, month or year)

This set is missing a few date time inputs that would make sense in such a more complete collection of granularity and floating (non-absolute) date time inputs:

* year      NEW: (specific year)
* month          (specific year, month)
* week           (specific year, week (implied month(s)))
* date           (specific year, month, day)
* datetime       (specific year, month, day, time)
* datetime-local (specific year, month, day, time, timezone)

and

* month-day NEW: (specific month, day)
* time           (specific time, but no specific day, month or year)

new datetime input use-cases

• year - see the time element year only use cases
  • pull-down for Wikipedia which lets you choose the year or period
  • a charting application which looks at trends in history
  • e-commerce: buying, say, automobile or building insurance and specifying the year of manufacture/ construction
• month-day - see time element month day only use cases
  • inputting a birthday without birth year
  • entering custom annual holidays
  • searching an "on this day in history" archive e.g. [1]
• Non-Gregorian/ BC dates
  • The Victoria & Albert Museum's collections search uses a drop-down menu to select BC/AD on the date fields

Additional use-cases for each of these new inputs are documented in proposals for allowing the respective levels of granularity/floating date/time support in the time element.

new datetime input discussion

Opinions / discussion:

• +1 Tantek - any implementer that is going to the trouble of properly implementing the existing 6 new date time inputs will find it fairly easy to implement two additional variants, and this more complete model of date and time inputs will be easier to remember for web authors (fewer exceptions to remember).
• +1 Andy Mabbett - Per the above, and examples/ use cases on time element.
• +1 Ryosuke Niwa on whatwg list - "... to implement that, we need to know that certain text field is accepting "year", not a 4-digit number."
  • +0 Aryeh Gregor on whatwg list - "I agree, this is a valid reason to want a year input. I can't say whether it's good enough to add it to the spec, given how many input types we have already and how little implementation has been done so far, but it's a legitimate argument."
  • +1 Jonathan Castello on whatwg list - "That's probably the most convincing point for adding a "year" type I've heard so far. I'd agree with a "year" type just based on that."
• +1 Sicking - The extra implementation cost is pretty low, and the uses are common enough. It's also tricky to work around the lack of day+month input since you can't leverage the existing controls, but rather have to start from scratch. However I think we should use the string "day-month" rather than "month-day" since most of the world, including most of the world that uses the english words "day" and "month", puts day before month. See [2]
• ...

new datetime input FAQ

how is a year different than a four digit number

Question: How is a "year" input any different from a four-digit input type="number" field?

Answer: 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" methodology.
• 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)
• Years can also be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD.
  • Sites requiring BC and/ or 1/2/3- digit year entry: [3], [4], [5]

how does year provide additional validation

Question: What sort of additional validation you would need in a year field that you couldn't accomplish with "number" with a size of 4?

Answer: See above for the additional semantics that a year provides above and beyond a 4 digit number (and that years are not necessarily 4 digits). One source of additional validation could come from only permitting years since the transition to the Gregorian calendar, unless another calendar scale is specified (see related Time element proposal).

how would a year input appear in visual UAs

Question: How would such an input would appear in visual UAs?

Answer: 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).

See Also

• time - the time element, related proposals.