[whatwg] Date/time field types - min, max, popup UI.
sigurd at silverstripe.com
Mon Sep 7 15:40:02 PDT 2009
In looking at the HTML 5, I have noticed an opportunity to provide
additional elements to support date and time field types. (Or, if I am
mistaken, it may simply be an opportunity to improve documentation of
an existing feature).
Whereas most field types have a Min and Max attribute, this does not
appear to be true of date/time fields.
If this is true, it means that this remains a task to be done at the
I suggest that the use of min and max on dates/times is frequently
required in forms, and that having this specified in HTML is both
convenient for writers of HTML, and as bonus, would appear to be a
light-weight task for those writing browsers.
In my professional experience of building websites since 2000, most
date fields in forms fall into one of two patterns:
1. A Date of Birth field.
2. A Booking/reservation date field.
If we examine these two patterns, we see that (1) will typically be a
date in the past 100 years, whereas (2) will typically be a date in
the upcoming few weeks, months, or years. This shows that most fields
have a natural need for a min and max attribute. Sometimes the date is
a specific point in the past or future, and other times the current
Therefore the usefulness of the input would be greatly expanded with a
syntax something like this pseudocode:
<input name="DateOfBirth" type=datetype min="1900-01-01" max="now">
<input name="HotelBookingStart" type=datetype min="now"
I recognise there is potential to use the pattern attribute, or to say
max="5 years from today" but I wonder if we should focus on the
basics, first. That said, having some way of semantically describing a
date of birth field as distinct from other date fields would allow
user agents to remember and subsequent pre-populate the value. Has
this been considered?
One valuable benefit of having max and min is it can be used to aid
the usability of calendar pop ups -- dates beyond the min/max can be
"greyed out" and prevented from being selected. It reduces user error
by reinforcing a selection in the past or future.
I see that the spec does not appear to concern itself with the
presentation of date pickers. Is there any guidance or research that
can be offered to user agents to do a good job of this? From a
usability perspective, I see a number of issues. Two that come
instantly to mind:
1. What do you show to the user initially? A text box with a calendar
icon, which when single-clicked, opens a popup? This is common with
web forms but there are many situations where this user experience
should be challenged. Sometimes you want to show the calendar embedded
into the form/page itself. This is useful where picking a date is key
aspect of what you are doing, and by doing this you prevent an extra
step of having to 'open' the calendar. Without guidance user agents
may end up with quite different user experiences and options in both
the initial state of a field as well as how they present a calendar
picker. Having uniformity of this experience across browsers is helpful.
2. The majority of date fields are for choosing a date in the next 8
weeks. (Consider your hotel, flight, movie, etc, bookings.) This makes
most calendar popups frustrating because they will solicit for a date
of the current month. If they show this AND next month together, e.g.
September 2009 and September 2010, then it allows a user to readily
choose a date that is already visible to be clicked. You'll appreciate
when you use a calendar picker in the second half of a month, the
chance that you will choose a date in the current month is less and
less. You therefore need to click ahead to choose your date. American
Airlines show a two-month calendar pop up that has good usability
(although the same cannot be said of the visual design) - Screenshot: http://www.flickr.com/photos/sigurd/3897538057/
. Therefore, having some sort of semantic way to describe a date
field as a "booking" field would allow user agents to innovate and
present a calendar picker optimised for choosing a date in the
There are other related issues like the use of the 'pattern' attribute
and how dates are localised, but the above gets this discussion
rolling. Thanks to Bruce Lawson at Opera for positive feedback on this
issue at OSCON this year and suggesting I discuss it here. I
appreciate your thoughts.
More information about the whatwg