> How about we get around to <input type=date> now?

It's been in Chrome stable for five weeks now. :) <input type=color> as well. http://miketaylr.com/code/html5-forms-ui-support.html

Chrome's webforms status is here: http://www.chromium.org/developers/web-platform-status/forms and www.chromestatus.com usually captures everything else.

Probably the wrong place to ask...

Why does <input type=date> display the field in format MM/DD/YYYY in the field but the value property is formatted in YYYY-MM-DD?

Is the former a localization setting and the latter the standardized format? Is there any customization available? Also, no input[placeholder] support.

Example: http://jsfiddle.net/dUc5V/3/

It displays based on locale. YYYY-MM-DD is the ISO Standard[1], which is also used in ES5 as the standard date/time representation.

[1]http://en.wikipedia.org/wiki/ISO_8601

It's probably localization, yes, since to me it shows up as DD-MM-YYYY.

Oh hi π.

My bad, I didn't realise Chrome had it yet.

Now I just need a use for it...

I have been using input type date a lot recently. My app is chrome only and has to serve not very tech oriented people. And telling them to add date in a specific format is a huge pain in the ass. So input type date and even color to some extent have saved me a ton of support time. Although the interface can be better. It looks like a poorly designed html popup. (Although it is probably exactly that since chrome uses shadow DOM)

What part of your app requires that it be "Chrome only"? There are tons of Javascript UI libraries that can handle date inputs cross-browser such as jQuery UI. http://jqueryui.com/demos/datepicker/

Yes, i am familiar with libraries, but since i will have physical access to all the user's computers (it's an app for a school's teachers) i though i might as well just support the newer browsers and don't support older ones at all. And i am also not a fan of libraries like jquery. Most of the modern browsers can do what they do a lot quicker.

And i should have mentioned, it is not strictly chrome only, but i have told all teachers to use chrome because firefox does not have date pickers yet. But the site is still completely functional in latest firefox and safari plus ie10 (provided teachers add dates manually). I just don't like using libraries at all. I try to avoid them until absolutely necessary. So much that i have never had to use jquery, or any other library for that matter. The app in question is quiet elaborate (feature wise) but still does not have a single file not written by me. It may not be the wisest thing to do, but it makes me comfortable to know exactly what my code is doing.

Yeah, it doesn't feel native. It looks like something from a Google GUI framework.

It uses GTK native color picker in linux, but the date input is not native one.

I noticed that myself. I'd kinda prefer a browser picker, but I suppose using OS controls is good generally.

Why are you complaining about the lack of a feature that you don't have a use for?

Someone else pointed it out in another thread, and I'm also bothered by it, that we seem to be gaining advanced hardware access etc. yet seemingly not basic form controls. Although I was mistaken on the Date picker.

http://behero.us/ reused the xylophone code to build something like guitar hero

Cool, but "Kinect in the browser" is a gross exaggeration on their part.

sure, they would need a (reduced) stick figure detecture for it to be a proper kinect in the browser.

And they don't even have any of that lovely depth information.