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.
> 2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future.
Why do you care what the UI looks like? As long as the API is stable.
> 3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain.
I count this as a plus, honestly.
> 4. There are better JS-based datepickers out there for the desktop.
Ugh. The less we rely on javascript for basic functionality the better.
You're js, highly themed date picker probably isn't very accessible and probably doesn't function like the rest of the system does either.
The more we can leverage the User Agent, the more we should. It's easier on developers. It's more accessible. It's more consistent across the user's platform.
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.
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.
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.
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.
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++?
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.
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.
Right, but what happens when there is a problem with the datepicker? How does the web dev debug that? It could be on the browser end, could be a problem with the html, or even the backend? What a nightmare.
You recommend using a JS-based datepicker, what would the difference be?
This would be faster and easier since you don't have to keep the JS-based one up to date.
Their existence is why this is such a popular browser feature request:
http://msdn.microsoft.com/en-us/library/system.windows.contr...
https://developer.apple.com/library/mac/documentation/Cocoa/...
1. They will provide different UI across different desktop browsers/OS's, etc. The theory was that the browser can decide what the datepicker should look like. The practice is that half of them are ugly or lack the UI you want and you can't do much to fix that.
2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future.
3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain.
4. There are better JS-based datepickers out there for the desktop.
The only reason to use <input type="date"> IMO would be for a mobile-only site. iOS/Safari uses a stable native date implementation which is awesome. However, on the desktop, there is no standard datepicker widget to use the same way, so it just ends up looking weird.
What I would actually love is an <input> type that lets me just type in a date (think a date of birth field) where the input is perfectly validated. That's right, in 2014 with out state of the art browsers, this is still nearly impossible. Sure you can use a regex, but have you tried putting together a regex that validates 2/29/2012 vs 2/29/2014 vs 2/29/1900? On top of that, the patter= attribute doesn't prevent you from typing/pasting, it only provides a place to put validation that's optional. A callback mechanism for as-you-type validation would be so much better.