Can the HTML5 date input field survive?

Yesterday I ran across a Google+ conversation from Google Chrome Developers which happily announced that the “Date Picker landed on Chrome Canary and Chromium!“. So far I have not paid much attention to the date type input field. But I participated in this thread and researched the background of the date type input specification as well as the existing browser implementations of it. I began to wonder if this thing was really going to succeed as a widely used tag if every browser implements a different calendar-like date-picker control.

It will definitely be excellent if we can eventually create date fields that give us great date-picker controls in most browsers, without extra JavaScript. But right now I have a few serious concerns for these date-picker’s long term survival and <input type=date> in general.

Concern #1: Appearance

Here was the screenshot presented in the Chrome date-picker post:

Many of the commenters in the thread, including myself, bemoaned the appearance of the control and hoped that it would be styleable. Paul Irish helpfully commented:

This implementation is not final. Your constructive feedback is useful in helping Chrome identify what can be improved.

There is a guide to styling form controls in WebKit here: http://trac.webkit.org/wiki/Styling%20Form%20Controls I don’t see anything on the date inputs yet, but we’ll see. :)

Also, here is the style for the widget:
http://trac.webkit.org/…/calendarPicker.css

OK, awesome — pretty much everything about this can be re-styled (for Chrome at least). Which is great, since many websites will need to tweak this appearance. I really hope that the final default Chrome styling looks significantly better than this screenshot (though admittedly I haven’t lifted a finger to help out by tweaking this built in Chromium style). Whether frontend developers can get these things looking as good as existing date-picker controls (such as jQuery UI’s) will certainly have a huge influence on whether <input type=”date”> continues to grow in use.

However, there is a real secondary concern here in that it doesn’t seem like all the browser vendors will be using those same CSS selectors. Opera’s calendar date-picker looks very different than Chrome’s (and, in my opinion, much worse):

Based on the information I can find out there, you cannot style Opera’s date-picker control. Even worse, you can’t type into it (you can in Chrome), which is a completely different behavior to stable Chrome and Safari (both of which allow typing but neither of which have a calendar control yet). Wufoo has some good information about Opera’s date-picker as well as the limited date input type implementations available in stable Chrome and Safari.

The iPhone Safari date-picker is radically different, looking nothing like a Calendar:

However, I think that this difference is acceptable due to the constraints of a mobile device.

So it seems like appearance in Chrome is a temporary issue, but the way these things look elsewhere and cross browser could remain an issue. But the appearance is only part of what worries me…

Concern #2: Date Formats

My bigger concern is with the format of the date. The specification has not allowed for any diversity in the input format. Based on the spec for the date input type, the value of the input field must be

A valid full-date as defined in [RFC 3339], with the additional qualification that the year component is four or more digits representing a number greater than 0. Example 1996-12-19.

RFC 3999 defines a full-date as:

full-date = date-fullyear "-" date-month "-" date-mday"

So it’s an ISO date, which has a format of YYYY-MM-DD. I’ve worked on and with many web and other applications that have date fields. While ISO date format is generally preferred by developers, it does not always go over well with users. I’ve often been forced to shuffle the date format, or dealt with bugs that had to do with users entering MM/DD/YY (US) or DD-MM-YY (Australia) into fields that wanted YYYY-MM-DD. I imagine in Europe you see problems due to entry of YYYY-WW dates (week of the year) in fields where you really want month and day. It doesn’t seem to matter what kind of help text or clues you give the user, some of them just won’t think twice about entering, for example, their date of birth in the form they are used to saying it out loud. Beyond that, sometimes for space constraints you might only want a Month & Day or Week-of-Year type of field without having to select a year, as long as the year is easily inferable from the context — shouldn’t <input type=”date”> or some similar type be able to deal with those easily?

Of course, there are ways to deal with this on the validation/normalization side of things with logic, either making reasonable guesses based on the numbers (31 can never be a month for example) or giving the user nice errors. Most JavaScript date-picker libraries have some capabilities in this area. Fortunately the spec for the date input type points to “setCustomValidity” which lets you specify your own validation logic (Although I’m not clear whether it’s legitimate to change the field value to a normalized value within setCustomValidity, which would be important if you want to allow a user to enter “1999/8/7″ and correct the value to “1999-08-07″ for instance).

But that’s exactly my worry here — the spec does not seem to account for any of these issues. Yes, there are a few other date and time fields available, but they still all have this basic inflexibility of formatting. Should users be allowed to use slashes instead of dashes? What about single-digit day or month values? Shouldn’t we be able to specify an alternative format besides the full-date format? It would be nice if this stuff was embodied in the spec — otherwise one or more of these things will happen:

  • Frontend devs will continue to have to hang extra logic over these fields to deal with these issues
  • Browser vendors will come up with their own, different, ways of dealing with these things over time
  • This input type will fail to supplant JavaScript solutions for date selection

Concern #3: Non-trivial use cases

There seem to be many non-trivial use cases for date fields in the real world that are not accommodated by any of the date related input types.

If you run across a date-picker in the wild, it is very likely that you’ll be picking a date range. Some sites offer a single control to select such a range, for example Google Analytics:

Wouldn’t it be swell if a built in HTML5 date input could do this? At the very least, shouldn’t it be possible to link two fields so that one could represent the start and one could represent the end, and the browser could properly control the interaction between them? I see that you can specify min and max, but these appear to expect an exact date value. I am sure you could write JavaScript to link the two, but this seems like such a common use case that the basic spec for the field should accommodate it.

You also frequently see two months displayed in one date-picker, which can be really handy. One example is Bing’s travel related search:

Again, I think this is so common it should really be part of the basic spec.

It also seems like there should be a way to specify default values such as “today’s date”, “end of this month”, “next business day”, “beginning of this month”, etc. Obviously you can plug those in on the server side or in client side templating, but still…

So where does that leave us?

I believe there are a few things that could be done to improve the spec for the input date type which would allow browsers to do better things more consistently. I have never really participated in the standards creation process, and I gather this ship has already sailed for the HTML5 date input type (feel free to berate me for my ignorance on these issues in the comments). Still, in a perfect world, we’d get something like these added to the spec (or new input types with similar capabilities):

  1. displayFormat – Attribute which would contain a normalized display format, so for example if the user typed 2012/4/18 the browser would change it to 2012-04-18
  2. monthsShown – Attribute which would specify the number of months to show, maybe maxing out at 12. Zero could be a useful value if you want to do the validation and normalization, but don’t need a picker (such as date of birth entry). In fact, that really deserves it’s own item…
  3. showCalendar – Attribute which, if set false, means we just want a text input field with appropriate validation
  4. minInput, maxInput – Attributes that would contain the ID of another date input element, which would link two (or more?) inputs
  5. inputFormats – Attribute whose contents would be some kind of (semicolon separated? not sure…) list of allowed formats, specified similarly to Java’s SimpleDateFormat patterns.
  6. defaultValue – Attribute with special values like “today”, “end-of-month”, “next-weekday” etc.
  7. a shared set of CSS selectors to control some of the basic appearance

Beyond that, it seems like some simple JavaScript libraries (much simpler than existing date-picker libraries) could hang these behaviors off the date input type (there probably already are). Which brings me to the things I ought to do about this (if I have the time):

  1. Write such a library
  2. Learn more about and get involved in the relevant specifications process
  3. Tweak the date input stylesheet for Chromium so that it looks a bit better (I can only take this so far, not really being a graphic designer) and submit a revision

Anyway, I hope this commentary will be seen as constructive and not just untimely bellyaching. If anything, it should be motivation for me to get involved in these kinds of issues sooner. It will be interesting to see how this input type fairs as browsers continue to implement better controls for it. I wish it the best of luck.

10 Responses to Can the HTML5 date input field survive?

  1. There are other HTML5 input types that cater to selecting a specific month or week of a specific year. Type=date is really just for when you need the day too.

    Of course, who knows how well supported those input types are?

  2. Thanks Ron, I do know that, but rereading I am not surprised it wasn’t clear. When I mentioned entering the week of the year, I meant people typing in YYYY-WW into a field that wanted YYYY-MM-DD. Should have been clearer… thanks

  3. My main problem with this date picker on chrome is that there’s no easy (or even ANY!) way to disable it, except for changing the type attribute.
    I don’t really want to do that, since it’s unsemantic.. :|

  4. Pingback: HTML5: New Input Types | Steve's .NET Space

  5. Agree! Nice sum-up. This is a nice to have feature BUT I would have much preferred that Google delayed the release until there was at least a way to disable it- since now I need to do a mad dash to change the my input type to plain old text. Which is really unfortunate!

  6. Pingback: Native HTML5 Date Picker in Chrome 20 | Rhys Lloyd

  7. Great summation! I really am dismayed Google released this “feature” in such beta form. It seems very poorly thought out. I hope someone at Google reads your post.

  8. I’m in Australia, and was starting to panic about the date format, but it appears that the picker detects localisation settings – the field has an inbuilt placeholder with DD/MM/YYYY. It also converts a date entered in ISO full date format into the localised format.

    It also prevents picking of dates outside the min/max values, but it still doesn’t do anything about manual entry of out of bounds dates.

  9. Personally I would have thought we would have learned from the fact that form-elements have always been hard to style (think of checkboxes, radiobuttons and select-boxes). It seems madness to me to add yet a bunch of other difficult-to-style stuff to the browser.
    Why don’t they just add a “placeholder” to such elements (sort of like a hidden built-in div, or the datalist element) that one can use to populate and style with whatever we want/need.
    Also, regarding date-formats: I have always been a proponent of using one universal time-format AND time-zone to store and transmit dates and times (e.g. UTC UNIX timestamp) which can then be converted to any format or time-zone before displaying (or after submitting). This is something browsers could do based on localization settings.
    So my 2 cents: add time-zone conversion and let developers use UTC UNIX timestamps always, and drop the difficult-to-style stuff and just add an empty hook like the datalist-element.

  10. #1 surely this is a move back to the founding principle of the web. the browser decides how to render the html. You can criticize the chrome date picker for not looking pretty, but I bet it always pops up on the screen regardless of resolution, uses the local date format, is touch friendly on mobile devices etc.

    #2 it will do date formats better than javascript

    #3 yes but here you are essentially making your own date range control. why would expect the date input to handle it any better than a select?