- From: Sigurd Magnusson <sigurd@silverstripe.com>
- Date: Tue, 8 Sep 2009 10:40:02 +1200
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
Received on Monday, 7 September 2009 15:40:02 UTC