Reputation: 2017
I've just been through Mark Pilgrim's post on html5 form widgets here:
http://diveintohtml5.ep.io/forms.html
He implies that these elements should be adopted because they fallback to input=text. However on an (admittedly brief) test, it strikes me the behaviour of the date input, at least in safari, is actually inferior to a straight text input validated on the server.
Any views on this?
Upvotes: 4
Views: 908
Reputation: 20862
Here's a reason not to use type="date"
(or at least to do so carefully): localized date formats.
If you use <input type="date">
and the browser supports the date
type, then you must specify the value
attribute in ISO-8601 date format (like yyyy-MM-dd). If the browser does not support the date
type, then you are going to want to show the date in the user's local date format (e.g. MM/dd/yyyy in the US).
On the server side, you could probably get sloppy and do something like this:
try
parse date as ISO-8601
catch (Format Error)
try
parse date as local format
catch (Format Error)
show user error message
If you want to be as explicit as possible, you'll have to do some feature-detection on the client side, then enable type="date"
, then change the date format of the value
attribute, and maybe even manufacture a hidden form element that notifies the server that the date format coming from the form should be ISO-8601.
Upvotes: 1
Reputation: 163262
As pointed out in your article, and the comments, there is no reason not to use this input type.
For browsers that do not support type="date"
, the attribute will be ignored, and the field will render as type="text"
, as that is the default.
You will want to validate that date server-side. Remember: Anyone can post anything to your scripts.
You can still validate the data client-side. There are methods for detecting HTML5 form support here: http://nicolahibbert.com/html5-forms-support-detection-javascript/
Upvotes: 1