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.
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:
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?
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
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:
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):
- 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
- 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…
- showCalendar – Attribute which, if set false, means we just want a text input field with appropriate validation
- minInput, maxInput – Attributes that would contain the ID of another date input element, which would link two (or more?) inputs
- inputFormats – Attribute whose contents would be some kind of (semicolon separated? not sure…) list of allowed formats, specified similarly to Java’s SimpleDateFormat patterns.
- defaultValue – Attribute with special values like “today”, “end-of-month”, “next-weekday” etc.
- a shared set of CSS selectors to control some of the basic appearance
- Write such a library
- Learn more about and get involved in the relevant specifications process
- 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.