Hi all,
I just got a little burned by Chrome's new date popup for HTML date-type
inputs!
*Why?*
- Because when I wrote the original code, I hadn't read up on the new
properties being added to HTML5 input types
- Because I was using a js-based datepicker plugin to implement the same
functionality and wasn't feature-detecting native date handling (except for
mobile devices)
- Because my JS expects a particular date format, and could only handle
Australian dd/mm/yyyy or ISO8601-compliant date strings. This wasn't an
issue before, because my JS datepicker controlled the format.
*How do I avoid making the same mistake?*
HTML5 implements a new property for input types that deal with date or time
values:
element.valueAsDate
This property is designed to solve your locale woes, and it is also an easy
way to feature-detect a browser's native support for the date input type. I
haven't gone through all current browsers yet, so if you do use this
method, make sure to check that none of your browsers support the property
without implementing a date picker.
.valueAsDate, as you might have guessed, returns the input's value as
a Dateobject. Here's a super-simple feature detect:
if ( !myElement.valueAsDate ) {
// Implement my JavaScript datepicker
}
*The result*
Better usability! (and more robust date handling).
*For your convenience*
I have created a jsFiddle you can run on any browser to test the feature
detection: http://jsfiddle.net/h9jYB/5/
- Opera 12: *Pass *(valueAsDate handling, datepicker present)
- Chrome 20: *Pass *(valueAsDate handling, datepicker present)
- Firefox 12: *Pass *(no valueAsDate handling, no datepicker)
- IE8, IE9: *Pass *(no valueAsDate handling, no datepicker)
- James
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******************************************************************
