3 ms·

> The difference between <input type="text"> and <input type="date"> is that the former has been around for 2.5 decades and looks nearly identical across all br

> The difference between <input type="text"> and <input type="date"> is that the former has been around for 2.5 decades and looks nearly identical across all browsers So because something hasn't been around we shouldn't get it to exist. > Also, note that you can style <input type="text"> quite a bit: different fonts, different border, different colors, padding, adding icons, placeholders, focus/unfocus behavior. Lastly, note that text inputs are extremely simple: the interaction is to get focus, type/select/copy/paste/unfocus. A datepicker is orders of magnitude more involved. This couldn't be done for a datepicker? Those behaviors and styles couldn't be standardized. > Design-wise, yes it matters a great deal. And this is how we get buttons that don't work correctly with keyboard inputs; people reinventing the wheel because they can't stand not having absolute control over every aspect of their design. > Once again, in theory a nice well thought-out universal datepicker built right into the browser would be fantastic. In practice, I don't see that happening and the inferior JS-based alternatives end up working better in real-world products. Once again, I don't understand why people think having a myriad of input styles and behaviors via JS is better than a speced standard input supported by the majority of browsers, accessible, and well-defined behaviors.

IgorPartola 12y ago
> Once again, I don't understand why people think having a myriad of input styles and behaviors via JS is better than a speced standard input supported by the majority of browsers, accessible, and well-defined behaviors. 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/statement.html http://dojotoolkit.org/reference-guide/1.10/dijit/a11y/state.... Also, what do you think the native chrome widget is built with, C++?
- megalodon 12y ago
  > 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.

IgorPartola 12y ago

> Once again, I don't understand why people think having a myriad of input styles and behaviors via JS is better than a speced standard input supported by the majority of browsers, accessible, and well-defined behaviors. 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/statement.html http://dojotoolkit.org/reference-guide/1.10/dijit/a11y/state.... Also, what do you think the native chrome widget is built with, C++?

megalodon 12y ago
> 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.