[whatwg] Date/time field types - min, max, popup UI.

[Sigurd Magnusson]

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  
javascript level.

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  
timestamp.

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">
or
<input name="HotelBookingStart" type=datetype min="now"  
max="2020-12-31">

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  
imminent future.

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.

Sigurd.


-------
Sigurd Magnusson
SilverStripe
www.silverstripe.com
www.silverstripe.org