> The implementation is left entirely up to the browser.
This is the problem. Why not make standard inputs have OS-based UIs instead of browser-based? It would at least provide some design consistency. Could be harder to implement though.
This is the problem. Why not make standard inputs have OS-based UIs instead of browser-based? It would at least provide some design consistency. Could be harder to implement though.
Because there is no speced standard input. The only speced part is the API and the markup. The implementation is left entirely up to the browser.
Once again, I am going to try to condense my point: date input is a great idea. A sane simple API for the datepicker would be great. In practice, how the widget looks and works (not the API, just the UI) has been left up the browser vendors who proceeded to screw it up on the desktop. Only one desktop browser currently supports it, and does a very poor job of making it actually usable. As is, <input type="date"> cannot be used on the desktop, IME. As I see no movement to actually spec out the UI, or to actually implement a standard customizable datepicker across all major desktop browsers, I think this effort should mostly be abandoned.
Instead I would like to see one of two solutions: (a) keep <input type="date"> and its associated API's, etc. but allow developers to at least override the default widget. (b) Scrap the entire thing and start from scratch on a new spec that politically people can actually get behind.
P.S.: While terrible JS widgets to exist, there has been a huge movement to make them accessible. For example see http://dojotoolkit.org/reference-guide/1.10/dijit/a11y/state.... Also, what do you think the native chrome widget is built with, C++?