-
Notifications
You must be signed in to change notification settings - Fork 4
/
atom.xml
494 lines (300 loc) · 24.2 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[Category: jQuery UI | TJ VanToll]]></title>
<link href="http://tjvantoll.com/blog/categories/jquery-ui/atom.xml" rel="self"/>
<link href="http://tjvantoll.com/"/>
<updated>2012-10-22T20:57:18-04:00</updated>
<id>http://tjvantoll.com/</id>
<author>
<name><![CDATA[TJ VanToll]]></name>
<email><![CDATA[tj.vantoll@gmail.com]]></email>
</author>
<generator uri="http://octopress.org/">Octopress</generator>
<entry>
<title type="html"><![CDATA[Using jQuery UI's Slider to Polyfill HTML5's input[type=range]]]></title>
<link href="http://tjvantoll.com/2012/09/14/using-jquery-ui-slider-to-polyfill-html5-input-type-range/"/>
<updated>2012-09-14T21:25:00-04:00</updated>
<id>http://tjvantoll.com/2012/09/14/using-jquery-ui-slider-to-polyfill-html5-input-type-range</id>
<content type="html"><![CDATA[<p><a href="http://jqueryui.com/demos/slider">jQuery UI's slider plugin</a> looks and behaves much like the browser's native <code>input[type=range]</code> control; therefore it makes an excellent choice for <a href="http://remysharp.com/2010/10/08/what-is-a-polyfill/">polyfilling</a> the native behavior.</p>
<h3>How to do it</h3>
<p>The main issue is that the slider must be built on a block level node, not an <code><input></code>. Therefore you must create another container node (in this case a <code><div></code>) to create the slider from then hide the original <code><input></code>.</p>
<p>Here's the script that I used.</p>
<!--more-->
<p>``` javascript Polyfill input[type=range] with jQuery UI's Slider
$(function() {</p>
<pre><code>//Determine whether the browser natively supports input[type=range].
//If you're using Modernizr this is equivalent to Modernizr.inputtypes.range
var input = document.createElement('input');
input.setAttribute('type', 'range');
var rangeSupport = input.type != 'text';
if (!rangeSupport) {
var $input, $slider;
$('input[type=range]').each(function(index, input) {
$input = $(input);
//Create a new div, turn it into a slider, and set its attributes based on
//the attributes of the input. If the input doesn't possess those attributes
//use jQuery UI's defaults.
$slider = $('<div />').slider({
min: parseInt($input.attr('min'), 10) || 0,
max: parseInt($input.attr('max'), 10) || 100,
value: parseInt($input.attr('value'), 10) || 0,
step: parseInt($input.attr('step'), 10) || 1,
slide: function(event, ui) {
//Keep the value of the input[type=range] in sync with the slider.
$(this).prev('input').val(ui.value);
}
});
//Append the slider after the input and hide the input. The user will only
//interact with the slider.
$input.after($slider).hide();
});
}
</code></pre>
<p>});
```</p>
<h3>Future</h3>
<p>This approach handles the most common use cases but it isn't perfect. For example, if you want to disable the <code><input type="range"></code> you'll have to disable the slider as well.</p>
<p>There is a <a href="http://bugs.jqueryui.com/ticket/5800">feature request to add support for this natively in the slider plugin</a> itself, but it's been sitting inactive for quite some time now. Hopefully over time <code>input[type=range]</code> support will become ubiquitous enough that we can drop these workarounds.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Native HTML5 Number Picker and jQuery UI's Spinner - Which to Use?]]></title>
<link href="http://tjvantoll.com/2012/07/15/native-html5-number-picker-vs-jquery-uis-spinner-which-to-use/"/>
<updated>2012-07-15T21:07:00-04:00</updated>
<id>http://tjvantoll.com/2012/07/15/native-html5-number-picker-vs-jquery-uis-spinner-which-to-use</id>
<content type="html"><![CDATA[<p><a href="http://www.w3.org/TR/html5/number-state.html#number-state">HTML5's native number picker</a> (<code><input[type=number]</code>) and jQuery UI 1.9's spinner can both be used to create inputs for numeric data. So which makes sense for your application? Let's start with a brief explanation of each.</p>
<h3><code>input[type=number]</code></h3>
<p>HTML5 adds several new valid <code>type</code> attributes for <code><input></code> elements. One of them, <code>number</code>, can be used to create a number picker.</p>
<p><code>html
<input type="number" />
</code></p>
<p>This will present the user with a number picker in supported browsers, which, as of this writing includes Chrome, Safari, Opera, iOS, Opera Mobile, and Android 4.0+ (<a href="http://caniuse.com/#feat=input-number">full support list</a>). Here's what the user will see in supported browsers:</p>
<!--more-->
<h5>Chrome 20:</h5>
<p><img src="/images/posts/2012-07-15/Chrome.png" title="Chrome" alt="Chrome" /></p>
<h5>Safari 5.1.7:</h5>
<p><img src="/images/posts/2012-07-15/Safari.png" title="Safari" alt="Safari" /></p>
<h5>Opera 12.00:</h5>
<p><img src="/images/posts/2012-07-15/Opera.png" title="Opera" alt="Opera" /></p>
<h5>Opera Mobile 12:</h5>
<p><img alt="Opera Mobile" title="Opera Mobile" src="http://tjvantoll.com/images/posts/2012-07-15/Opera_Mobile.png" style="height: 250px;" /></p>
<h5>iOS 5:</h5>
<p><img alt="iOS" title="iOS" src="http://tjvantoll.com/images/posts/2012-07-15/iOS.png" style="height: 200px;" /></p>
<h5>Android 4.1 (Jelly Bean):</h5>
<p><img alt="Android" title="Android" src="http://tjvantoll.com/images/posts/2012-07-15/Android.png" style="height: 200px;" /></p>
<p>As you can see one of the nicest effects of using <code>[type=number]</code> is that mobile users will automatically be presented with a number pad to aid with entry of numeric data. Unsupported browsers will simply treat the <code>input[type=number]</code> as a normal text input. Firefox has <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=344616">recently added a UI-less version</a> of <code>input[type=number]</code> to their nightly builds so hopefully a fully enabled version will be coming soon.</p>
<p>You can see what your browser does below:</p>
<iframe style="width: 100%; height: 120px;" src="http://jsfiddle.net/tj_vantoll/XMEEz/1/embedded/result,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h4>Additional Functionality</h4>
<p>The native number picker supports <code>min</code>, <code>max</code>, and <code>step</code> attributes to allow you to pick the minimum value of the <code><input></code>, the maximum value of the <code><input></code>, and the amount the value should be incremented / decremented when the user spins through values (the <code>step</code> attribute defaults to <code>1</code> if not specified).</p>
<p>For example, on the <code><input></code> below the browser will enforce that the minimum value will be <code>2</code>, the maximum value will be <code>20</code>, and the user will step at increments of <code>2</code>.</p>
<p><code>html
<input type="number" min="2" max="20" step="2" />
</code></p>
<p>You can see how this behaves in your browser below:</p>
<iframe style="width: 100%; height: 120px;" src="http://jsfiddle.net/tj_vantoll/YmQFS/embedded/result,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>Just as a word of warning, Android 4.1 and iOS 5 do not support the <code>min</code>, <code>max</code>, or <code>step</code> attributes.</p>
<h4>Methods</h4>
<p>In addition to the new attributes, supporting browsers also provide 3 JavaScript methods specifically for <code>input[type=number]</code>.</p>
<ul>
<li><code>stepUp(n)</code> - Increment the <code>value</code> of the <code><input></code> by <code>n</code>.</li>
<li><code>stepDown(n)</code> - Decrement the <code>value</code> of the <code><input></code> by <code>n</code>.</li>
<li><code>valueAsNumber</code> - Retrieve the <code>value</code> of the <code>input</code> as a JavaScript <code>number</code> variable (by default retrieving the <code>value</code> of an <code><input></code> returns a <code>string</code>).</li>
</ul>
<h3>jQuery UI Spinner</h3>
<p>jQuery UI's <code>spinner</code> is a new plugin due for jQuery UI's 1.9 release (currently in beta). The plugin by default looks and behaves much like the native number picker.</p>
<iframe style="width: 100%; height: 120px;" src="http://jsfiddle.net/tj_vantoll/scXYB/1/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>It also supports setting minimum, maximum, and step values through options rather than attributes.</p>
<p>``` html jQuery UI Spinner
<input id="spinner" /></p>
<script>
$(function() {
$('#spinner').spinner({
min: 2,
max: 20,
step: 2
});
});
</script>
<p>```</p>
<p>Example:</p>
<iframe style="width: 100%; height: 120px;" src="http://jsfiddle.net/tj_vantoll/N7UXT/2/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h3>Above and Beyond</h3>
<p>What really sets jQuery UI's <code>spinner</code> apart from the native picker is that it is extensible, customizable, and it brings a number of extra features. Here are some of the additional things that you can do.</p>
<h4>Paging</h4>
<p><code>spinner</code> takes a <code>page</code> option that allows you to define how much the <code>spinner</code> should step when the page down / page up keys are pressed. The example below shows a <code>spinner</code> with a <code>step</code> value of <code>1</code> and a <code>page</code> value of <code>10</code>.</p>
<iframe style="width: 100%; height: 150px;" src="http://jsfiddle.net/tj_vantoll/EvTeQ/1/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h4>Mousewheel</h4>
<p>If you want mousewheel support for a <code>spinner</code> all you need to do is include <a href="https://github.com/brandonaaron/jquery-mousewheel">Brandon Aaron's mousewheel plugin</a> and you get it automatically! Try it out on any of the <code>spinner</code> demos on this page.</p>
<h4>Currency</h4>
<p>Ever need to accept currency at certain defined increments? This example shows a <code>spinner</code> that spins through currency values at $25 increments, all with the same clean API.</p>
<iframe style="width: 100%; height: 150px;" src="http://jsfiddle.net/tj_vantoll/2wEe6/3/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>The formatting is localized through <a href="https://github.com/jquery/globalize/">Globalize.js</a>, therefore, if you want to handle different currencies all you need to do is pass in the appropriate <code>culture</code> and include the necessary JavaScript dependencies. Here's an example of an input that takes Euros.</p>
<iframe style="width: 100%; height: 150px;" src="http://jsfiddle.net/tj_vantoll/ppH7g/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h4>Time</h4>
<p>If you need to accept time data <code>spinner</code> can be used for that as well.</p>
<iframe style="width: 100%; height: 150px;" src="http://jsfiddle.net/tj_vantoll/2wEe6/5/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>The <code>page</code> option discussed earlier is used nicely here to make the up / down keys control the minutes and the page up / page down keys to controls hours. Try it out on the example above.</p>
<h3>24 Hour Times</h3>
<p>Since the <code>spinner</code> uses Globalize.js, you're free to use a time system different than the United States' nonsensical one.</p>
<iframe style="width: 100%; height: 150px;" src="http://jsfiddle.net/tj_vantoll/Kenve/2/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h3>Time Picker vs. <code><input type="time"></code></h3>
<p>HTML5 also provides a native time picker (<code>input[type=time]</code>), but, it has <a href="http://caniuse.com/#feat=input-datetime">nearly no support</a>, does not yet provide localized formatting, and does not provide the stepping/paging functionality that <code>spinner</code> has baked in. In the future it might provide a viable native solution, but for now it's best to stay away.</p>
<h4>Extensible and Customizable</h4>
<p>Because <code>spinner</code> is built on top of <a href="http://ajpiano.com/widgetfactory">jQuery UI's widget factory</a>, it is easily extensible. For example, let's say you need to build an input that accepts a year in which the modern summer olympics were held. You could do that with the following:</p>
<p>```javascript Extending spinner
<input /></p>
<script>
$.widget( "tj.olympicspicker", $.ui.spinner, {
options: {
min: 1896,
max: 2012,
step: 4
}
});
$(function() {
$('input').olympicspicker();
});
</script>
<p>```</p>
<iframe style="width: 100%; height: 150px;" src="http://jsfiddle.net/tj_vantoll/EsTYd/1/embedded/result,js,html/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>Now all your olympics pickers in your code base can share the same code!</p>
<h3><code><input type="number"></code> vs. <code>spinner</code></h3>
<p>Although jQuery UI's <code>spinner</code> is more advanced and customizable, for most simple applications the native number picker will work just fine. If you simply need a field that accepts numeric data there's no need to bring in <code>spinner</code> as a dependency. However, if you do need the ability to fine tune the behavior and look of the picker, or if you need consistent UI across all browsers, jQuery UI's <code>spinner</code> provides an excellent API to do so.</p>
<p>To summarize the reasons to use the native picker are:</p>
<ul>
<li>Easy to implement, simply give an <code><input></code> a <code>type</code> attribute of <code>number</code>.</li>
<li>There are no dependencies, the number picker is native to the browser.</li>
<li>Mobile browsers that support the native picker will optimize the touch keyboard for number input.</li>
</ul>
<p>And the reasons to use jQuery UI's <code>spinner</code> are:</p>
<ul>
<li>Browser support - The <code>spinner</code> will work all the way back to IE6.</li>
<li>Extremely customizable and extensible.</li>
<li>Customizable handling of the page up and page down keys.</li>
<li>Easily integrated mousewheel support.</li>
<li>Built in custom types such as currency and time.</li>
<li>Built in i18n support.</li>
</ul>
<h3>Using jQuery UI's Spinner to Polyfill <code>input[type=number]</code></h3>
<p>Another option is to use the native HTML number picker when it's available, and fallback to jQuery UI's <code>spinner</code> when it's not.</p>
<p>``` javascript Using jQuery UI to Polyfill input[type=number]
$(function() {</p>
<pre><code>var input = document.createElement('input');
input.setAttribute('type', 'number');
if (input.type == 'text') {
$('input[type=number]').spinner();
}
</code></pre>
<p>});
```</p>
<p>The code to detect <code>input[type=number]</code> support was taken from <a href="https://github.com/jonstipe/number-polyfill">another number picker polyfill by jonstipe</a>. It creates an <code><input></code>, changes its <code>type</code> to <code>number</code>, and sees if that change actually took effect to determine whether the browser supports the type. You could also use the <code>Modernizr.inputtypes.number</code> check from <a href="http://modernizr.com">Modernizr</a> to achieve the same thing.</p>
<p>The <code>spinner</code> plugin is smart enough to look for the <code>step</code>, <code>min</code>, and <code>max</code> attributes on the <code><input></code> so you don't have to pass those in explictly (<a href="https://twitter.com/bassistance/status/225532234017406977">thanks @bassistance</a>).</p>
<p>The benefit of this technique is that you get the benefits of the native picker when it's available, and you can count on having a number picker in all browsers. As a further optimization you could even use a conditional script loader such as <a href="http://yepnopejs.com">yepnope.js</a> to bring in jQuery UI's required JavaScript and CSS only when you need it.</p>
<h3>Using Spinner and Getting a Number Keyboard on Mobile</h3>
<p>If you want to use a <code>spinner</code> everywhere AND get a number keyboard on mobile things get a little trickier. Mobile browsers look for an <code><input></code> to have <code>type=number</code> to provide the number keyboard. So you think this would be as simple as creating a <code>spinner</code> on a <code><input[type=number]></code> node. However, that produces the following on supporting desktop browsers.</p>
<h5>Chrome 20:</h5>
<p><img src="/images/posts/2012-07-15/Chrome-Dual.png" title="Chrome" alt="Chrome" /></p>
<h5>Safari 5.1.7:</h5>
<p><img src="/images/posts/2012-07-15/Safari-Dual.png" title="Safari" alt="Safari" /></p>
<h5>Opera 12.00:</h5>
<p><img src="/images/posts/2012-07-15/Opera-Dual.png" title="Opera" alt="Opera" /></p>
<p>Obviously the double arrow UI is less than ideal. So to work around this you simply need to hide or destroy one of the sets or controls... right?</p>
<p>Well it turns out hiding the native arrow controls is difficult because Chrome places the control on the inside of the <code><input></code> and Safari and Opera place it on the outside. Therefore, if you try to adjust the <code>margin</code> of the <code><input></code> so jQuery UI's controls overlap the native ones it won't work in a cross browser friendly way.</p>
<p>Therefore the best approach I've came up with is to hide the <code>spinner</code>'s arrow controls when the browser creates its own.</p>
<p>``` javascript Number keyboard for a spinner
$(function() {</p>
<pre><code>$('input[type=number]').spinner();
if (Modernizr.input.step) {
$('.ui-spinner-button').hide();
$('.ui-spinner-input').css('marginRight', 0);
}
</code></pre>
<p>});
```</p>
<p>What this does is detect whether the browser supports the <code>step</code> attribute, if it does it removes jQuery UI's controls. What does the <code>step</code> attribute have to do with the arrow controls? Nothing, except that it just <em>happens</em> that the browsers that support the <code>step</code> attribute also create a native control to do the stepping. Is this going to change in the future? Quite possibly.</p>
<p>So obviously this is not ideal, and probably shouldn't be used in production code, but it works at the moment. Have a better approach for tackling this problem? Let me know in the comments.</p>
<h3>Update (August 26th, 2012)</h3>
<p>Commenter amir pointed out the WebKit provides a pseudoclass that you can use to style, and therefore hide the native spin controls.</p>
<p>``` css
input[type=number]::-webkit-outer-spin-button {</p>
<pre><code>display: none;
</code></pre>
<p>}
input[type=number]::-webkit-inner-spin-button {</p>
<pre><code>display: none;
</code></pre>
<p>}
```</p>
<p>This solves the issue for Webkit, but this remains an issue for Opera and browsers that add <code>input[type=number]</code> support in the future.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Creating a Native HTML 5 Datepicker with a Fallback to jQuery UI]]></title>
<link href="http://tjvantoll.com/2012/06/30/creating-a-native-html5-datepicker-with-a-fallback-to-jquery-ui/"/>
<updated>2012-06-30T17:06:00-04:00</updated>
<id>http://tjvantoll.com/2012/06/30/creating-a-native-html5-datepicker-with-a-fallback-to-jquery-ui</id>
<content type="html"><![CDATA[<p>The recently released Chrome 20 features support for native datepickers on <code><input></code> nodes with a <code>[type=date]</code> attribute. The list of browsers that support native datepickers now includes Chrome, Opera 11+, Opera Mobile, and iOS 5+ (see <a href="http://caniuse.com/#feat=input-datetime">caniuse.com</a>). Therefore, now is a great time to start using them in your web applications.</p>
<!--more-->
<h3>Using</h3>
<p>Using the native datepickers is easy, just change the <code>type</code> attribute of your date inputs from <code>text</code> to <code>date</code>.</p>
<p>``` html Converting to a native HTML5 datepicker</p>
<!-- Before -->
<p><input type="text" /></p>
<!-- After -->
<p><input type="date" />
```</p>
<p>Here is what the user will see in supported browsers:</p>
<h4>Chrome 20</h4>
<p><img src="/images/posts/2012-06-30/Chrome.png" title="Chrome 20" alt="Chrome 20" /></p>
<h4>Opera 12</h4>
<p><img src="/images/posts/2012-06-30/Opera.png" title="Opera 12" alt="Opera 12" /></p>
<h4>Opera Mobile</h4>
<p><img src="/images/posts/2012-06-30/Opera%20Mobile.png" title="Opera Mobile" alt="Opera Mobile" /></p>
<h4>iOS 5</h4>
<p><img src="/images/posts/2012-06-30/iOS5.png" title="iOS 5" alt="iOS 5" /></p>
<h3>Advantages</h3>
<p>Why would use the native solution?</p>
<p>First and foremost there are no dependencies. There is no need to bring in a library or toolkit, it's all native. Therefore, you save some bytes by not having to ship the JavaScript / CSS to make the datepicker work.</p>
<p>Furthermore you can be guaranteed that it will work perfectly on all devices that support the native datepicker. It's not dependent on JavaScript so it'll even work for users that have JavaScript disabled.</p>
<p>Another key advantage is that devices can give alternative means of input for date controls. For example note the native date control in iOS 5:</p>
<p><img src="/images/posts/2012-06-30/iOS5.png" title="iOS 5" alt="iOS 5" /></p>
<p>It will be a lot easier for the user to input a date with those controls, plus you can be guaranteed that you'll receive input in the correct format.</p>
<h3>Disadvantages</h3>
<p>The main disadvantage of using a native datepicker is that you have a lot less control. There are no hooks to control the look of the date picker; you get what the browser wants to give you. You also have a lot less control over the behavior. Here's a small sampling of things that jQuery UI's datepicker can do that you cannot do with the native control.</p>
<ul>
<li>Only allow selection on certain days of the week.</li>
<li>Control the formatting of the headers in the control (Monday vs Mon vs M).</li>
<li>View multiple months at the same time.</li>
</ul>
<p>If any of this functionality is important to your application you'll probably want to stick with the jQuery UI solution.</p>
<h3>Best of Both Worlds</h3>
<p><a href="http://modernizr.com">Modernizr</a> gives you the ability to detect whether the browser supports native datepickers. The following shows how you can use the native datepicker when available, and fallback to jQuery UI's picker in unsupported browsers.</p>
<p>``` javascript Detect native support for datepickers and fallback to jQuery UI
if (!Moderniz.inputtypes.date) {</p>
<pre><code>$('input[type=date]').datepicker();
</code></pre>
<p>}
```</p>
<p>You can see how your browser handles this situation here:</p>
<iframe style="width: 100%; height: 120px;" src="http://jsfiddle.net/p58bt/2/embedded/result,html,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h3>Another Option</h3>
<p>Another option I like is showing the native date picker only to users that are on touch capable devices.</p>
<p>``` html Native picker for supported touch users only
<input type="text" id="myDate" /></p>
<script>
if (Modernizr.touch && Moderniz.inputtypes.date) {
document.getElementById('myDate').type = 'date';
} else {
$('#myDate').datepicker();
}
</script>
<p>```</p>
<p>This gives touch users with <code>input[type=date]</code> support the optimized UI / keyboard and everyone else jQuery UI's picker.</p>
<h3>Conclusion</h3>
<p>With Chrome adding support for native datepickers a large chunk web users now have the ability to use them. Therefore, now is a great time to consider using them in your applications.</p>
<h3>Update - September 15th, 2012</h3>
<p>I updated one of my code examples from using <code>$('input').attr('type', 'date')</code> to <code>document.getElementById('myDate').type = 'date'</code> after commenter brownieboy pointed out that jQuery actually doesn't allow you to change an input's <code>type</code>. jQuery does this because IE <= 8 does not allow an the <code>type</code> of an input to be changed at all. The native JS solution works just fine.</p>
]]></content>
</entry>
</feed>