We want to use HTML5 date fields where we can, but there are going to be a lot of issues.
There are a whole list of possible fields to use: date, datetime, datetime_local, week, month, etc. (see http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-and-ti...)
If you go to http://html5test.com/ and test various browser support, you can see that none of the HTML5 date fields work reliably across desktop browsers. In fact I only found one desktop browser that supported any HTML5 date field -- Chrome supports the 'date' type but nothing else.
These fields are really only supported on mobile devices.
I discussed this with some core maintainers in Munich, and the initial idea was that core would not provide any backwards compatibility -- it will be html5 or nothing. I think that's going to be a poor desktop UX, but that's just me. And I suppose somewhere between now and when core actually ships a production-ready version maybe desktop browsers will catch up.
So we need to use html5, but also recognize that it often will not work.
The date module currently creates date_text, date_popup, and date_select elements, each of which need to be examined to see how best to include html5. I hope we can then get them into core.
The date_select widget would not have any html5 settings, so it will work the same everywhere. The current date_popup expands into a 'date' and 'time' field, where the 'date' element uses the jQuery datepicker. That element could be reworked to use a html5 date element, but we need to clarify the fallback behavior so the jQuery widget can be used on all the desktop browsers that don't support html5 date. The time element could either become a drop-down selector, or become a html5 time element. We currently have a jQuery timepicker on that element, so again we have to figure out fallback behavior. The current date_text field uses no jQuery, so it could be configured to be a html5 datetime element.
Some relevant issues I found:
More HTML5 browser info: