undefined | Better HN

0 pointsIgorPartola11y ago0 comments

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, while the latter does not/is not. 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.

Design-wise, yes it matters a great deal. Once again on iOS, <input type="date"> works better than any alternatives. On the desktop, it is markedly worse: you get strange colors, weird layout that doesn't match your design, etc. The look and feel is in the weird space design-wise: it doesn't match anything in your OS, but it also doesn't match the site's design (almost ever).

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.

0 comments

4 comments · 2 top-level

jimktrains211y ago· 2 in thread

> 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.

IgorPartolaOP11y 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/state.... Also, what do you think the native chrome widget is built with, C++?

megalodon11y 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.

gldalmaso11y ago

Also adding that internationalization, IIRC, for native date input on the desktop is entirely based on the browser locale.

That's neither user friendly nor developer friendly. It just sucks.

Can i18n become a real concern for specs anytime soon? The non-US world at large would be grateful.

In fact, these HTML5 form features have just basically fragmented the development of mobile and desktop web pages. If we're gonna have different sets of features for different platforms, that's fine. Just be clear about on the api level. It was better when the date input was not even implemented on the desktop, at least we could detect it and shim accordingly, now it's basically a false positive since it's implemented without any real effort.

j / k navigate · click thread line to collapse