Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Since some years some devices support <code>&lt;input type="date"&gt;</code> but others don't, so one needs to be careful. Here are some observations from 2012, which still might be valid today:</p> <ul> <li><p>One can detect if <code>type="date"</code> is supported by setting that attribute and then reading back its value. Browsers/devices that don't support it will ignore setting the type to <code>date</code> and return <code>text</code> when reading back that attribute. Alternatively, <a href="http://modernizr.com/">Modernizr</a> can be used for detection. Beware that it's not enough to check for some Android version; like the Samsung Galaxy S2 on Android 4.0.3 does support <code>type="date"</code>, but the Google/Samsung Nexus S on the more recent Android 4.0.4 does <em>not</em>.</p></li> <li><p>When presetting the date for the native date picker, be sure to use a format the device recognizes. When not doing that, devices might silently reject it, leaving one with an empty input field when trying to show an existing value. Like using the date picker on a Galaxy S2 running Android 4.0.3 might itself set the <code>&lt;input&gt;</code> to <code>2012-6-1</code> for June 1st. However, when setting the value from JavaScript, it needs leading zeroes: <code>2012-06-01</code>.</p></li> <li><p>When using things like Cordova (PhoneGap) to display the native date picker on devices that don't support <code>type="date"</code>:</p> <ul> <li><p>Be sure to properly detect built-in support. Like in 2012 on the Galaxy S2 running Android 4.0.3, erroneously <em>also</em> using the Cordova Android plugin would result in showing the date picker twice in a row: once again after clicking "set" in its first occurrence. </p></li> <li><p>When there's multiple inputs on the same page, some devices show "previous" and "next" to get into another form field. On iOS 4, this does not trigger the <code>onclick</code> handler and hence gives the user a regular input. Using <code>onfocus</code> to trigger the plugin seemed to work better.</p></li> <li><p>On iOS 4, using <code>onclick</code> or <code>onfocus</code> to trigger the 2012 iOS plugin first made the regular keyboard show, after which the date picker was placed on top of that. Next, after using the date picker, one still needed to close the regular keyboard. Using <code>$(this).blur()</code> to remove focus before the date picker was shown helped for iOS 4 and did not affect other devices I tested. But it introduced some quick flashing of the keyboard on iOS, and things could be even more confusing on first usage as then the date picker was slower. One could fully disable the regular keyboard by making the input <code>readonly</code> if one were using the plugin, but that disabled the "previous" and "next" buttons when typing in other inputs on the same screen. It also seems the iOS 4 plugin did not make the native date picker show "cancel" or "clear", but <a href="http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIDatePicker_Class/Reference/UIDatePicker.html">I guess that's an iOS 4 thing</a>.</p></li> <li><p>On an iOS 4 iPad (simulator), in 2012 the Cordova plugin did not seem to render correctly, basically not giving the user any option to enter or change a date. <em>(Maybe iOS 4 doesn't render its native date picker nicely on top of a web view, or maybe my web view's CSS styling has some effect, and surely this might be different on a real device: please comment or edit!)</em></p></li> <li><p>Though, again in 2012, the Android date picker plugin tried to use the same JavaScript API as the iOS plugin, and its example used <code>allowOldDates</code>, the Android version actually did not support that. Also, it returned the new date as <code>2012/7/2</code> while the iOS version returned <code>Mon Jul 02 2012 00:00:00 GMT+0200 (CEST)</code>.</p></li> </ul></li> <li><p>Even when <code>&lt;input type="date"&gt;</code> is supported, things might look messy:</p> <ul> <li><p>iOS 5 nicely displays <code>2012-06-01</code> in a localized format, like <code>1 Jun. 2012</code> or <code>June 1, 2012</code> (and even updates that immediately while still operating the date picker). However, the Galaxy S2 running Android 4.0.3 shows the ugly <code>2012-6-1</code> or <code>2012-06-01</code>, no matter which locale is used.</p></li> <li><p>iOS 5 on an iPad (simulator) does not hide the keyboard when that is already visible when touching the date input, or when using "previous" or "next" in another input. It then simultaneously shows the date picker below the input <em>and</em> the keyboard at the bottom, and <em>seems</em> to allow any input from both. However, though it does change the visible value, the keyboard input is actually ignored. (Shown when reading back the value, or when invoking the date picker again.) When the keyboard was not yet shown, then touching the date input only shows the date picker, not the keyboard. <em>(This might be different on a real device, please comment or edit!)</em></p></li> <li><p>Devices might show a cursor in the input field, and a long press might trigger the clipboard options, possibly showing the regular keyboard too. When clicking, some devices might even show the regular keyboard for a split second, before changing to show the date picker.</p></li> </ul></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload