> In theory they'd be more consistent across the platform, just like text and select boxes; I'm not seeing the problem. You're site doesn't need to have it's style imposed on every single control.
I agree about the in-theory part. In practice, it has not happened.
> Why do you care what the UI looks like? As long as the API is stable.
I don't. The designers do. And if one of the four major browsers looks like crap, the design doesn't get scrapped, but the datepicker does.
> Ugh. The less we rely on javascript for basic functionality the better.
Right. Then give me a validated input field where I can say "this is a date. Don't type in anything else" and the browser makes it work. Nobody has done that yet.
Basically, there is a difference between how things should work in theory and in the ideal world, and then there is the mess we deal with now and for the next 5-10 years. I'd rather have an imperfect solution that saves me developer time and gives the user a better experience, than a perfectly engineered solution where the only good thing is the API.
> I agree about the in-theory part. In practice, it has not happened.
Just like text boxes and select boxes, right? Which is why everyone is trying to re-invent them too? We all know how much those are loved.
> I don't. The designers do. And if one of the four major browsers looks like crap, the design doesn't get scrapped, but the datepicker does.
Obviously you do care otherwise you wouldn't be having this conversation. Also, the default controls don't look crappy.
> Right. Then give me a validated input field where I can say "this is a date. Don't type in anything else" and the browser makes it work. Nobody has done that yet.
Then you need to educate users on what a valid date looks like. I feel that that's much harder than using a standard date control.
> Basically, there is a difference between how things should work in theory and in the ideal world, and then there is the mess we deal with now and for the next 5-10 years
It's only an issue because everyone seems to think having absolute control over the look of their website at the expense of usability.
> I'd rather have an imperfect solution that saves me developer time and gives the user a better experience, than a perfectly engineered solution where the only good thing is the API.
I have no idea what you mean. Easier for the developer and better user experience would be the built in date picker. A built-in datepicker should be following a standard API similar to every other HTML element.
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.
> 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.
> 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.
> 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.
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.
I agree about the in-theory part. In practice, it has not happened.
> Why do you care what the UI looks like? As long as the API is stable.
I don't. The designers do. And if one of the four major browsers looks like crap, the design doesn't get scrapped, but the datepicker does.
> Ugh. The less we rely on javascript for basic functionality the better.
Right. Then give me a validated input field where I can say "this is a date. Don't type in anything else" and the browser makes it work. Nobody has done that yet.
Basically, there is a difference between how things should work in theory and in the ideal world, and then there is the mess we deal with now and for the next 5-10 years. I'd rather have an imperfect solution that saves me developer time and gives the user a better experience, than a perfectly engineered solution where the only good thing is the API.