Like many things with HTML 5 the Date and Time elements promise so much and yet the unevenness of the browser vendors makes their use perhaps more trouble than it is worth. One thing that the new input elements and input attributes offers is less client side development for common tasks, such as date and time pickers, and their accompanying data validation. It would be nice in some contexts to let the browser do the client side validation for you. Sure you may have to write add a regex to the page, but at least you won’t need to inject so much JavaScript. (You’ll always, of course, have to do server side validation. The browser isn’t the only way to post to the server.)
With that in mind I though I would see how well the date and time input elements are implemented and where they are not implemented, what remedies could be taken.
The Standard and Support
One of the things you should think about before using them in your code is the format of the data they produce. This could end up causing problems with your mitigation efforts. The Date input type is straight forward and will give you a date in the format of yyyy-mm-dd. DateTime, however, is a little odd. The format is yyyy-mm-ddThh:mm:ss. Notice the T between the date and time? It is a separator and it makes sense, but when trying to deal with browser support and working around them it causes a problem as we will see.
As far as browser support, only one browser, Opera, supports the full implementation, which gives you a date picker widget on clicking the date input element.
Chrome 17 and Firefox 11 don’t have the date picker. They at least recognize the required and pattern attribute. IE 9 doesn’t recognize anything.
Strategies
So starting with a simple form (all commentary refers to this page) I wanted to see, if I used the date and time functions, could I progressively enhance the page when the browser did not support it.
First I added each of the new input types in a simple fieldset with an output element so I could see the results of my operation. I set the element to required and added a pattern. If you don’t add a pattern any data will be valid, which is not what I wanted. I styled the input box to be red while it is in an empty state and green when data meeting the pattern has been entered.
<fieldset>
<legend>Date – Using pattern, required and oninput</legend>
<form oninput=”dateout.value=date.value”>
<input type=”date” id=”date” required=”" pattern=”[0-9]{4}-(0[1-9]|1[012])-(0[1-9]|1[0-9]|2[0-9]|3[01])” />
<output id=”dateout”>
</output>
</form>
</fieldset>
The results worked well in Opera. When you select the date the required field changes from red to green. And in the output field you can see the date value the the field has.
What about Chrome?
Chrome doesn’t have the date picker, but if you manually enter the date in the right format, you can get the required field validation to kick off correctly. The same is true for Firefox. However, that is a problem. I write my dates mm/dd/yyyy and in other parts of the world it is different. I can’t expect my users to put a date in just so it matches the format that the standard says I should use. Even if I give them an example, it is going to be a problem.
The solution to this issue is offer the user a way to pick the date and not worry about formatting. I decided to use the popular jQuery date picker and format the date to the HTML 5 standard. I also added a simple test using Modernizer to check for the date picker. No sense adding the jQuery if I don’t need it. Since this is a demo I didn’t do some of the dynamic script loading that I would normally do. It works great. (As a side issue I found the oninput event for the form no longer worked to add the resulting date value to the output element. I had to add a jQuery onchange event handler to have it display the result).
So far so good, but what about the other types of date time elements? Next on my example list is the date time. I build out the fieldset and added in the datetimepicker extension for the jQuery date picker. It mimicked the standard version for the most part. However, the T is not there. While it isn’t a huge issue, to get the two values from different browsers to match I will have to add a little extra code to deal with that. It is more of a nuisance.
I also encountered a problem with the step attribute on the time elements. Step allows you to indicate control the distance between selectable numbers. I configured the time picker to only allow hour changes. Using the jQuery plug ins the step attribute was no longer in play. So all the fine tuning that I had added to the HTML is mostly useless.
Conclusion
While the date and time elements show a lot of potential the lack of browser support makes them troublesome to use. If you are just using date or time, I would say go ahead an use it. The other forms of date time are more problematic. I found that to get consistent results (and use the jQuery plug ins I like) I would need to extend the plugins, which seemed to defeat the purpose of a plug in. It would make more sense in that case to drop the HTML 5. There are many ways to solve the issue, but at this point using all but time or date, will require more work than it is worth.
