undefined | Better HN

0 pointsjimktrains211y ago0 comments

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

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.

0 comments

5 comments · 2 top-level

IgorPartola11y ago· 2 in thread

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

jimktrains2OP11y ago

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

IgorPartola11y ago

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.

2 more replies

megablast11y ago· 1 in thread

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

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.

jimktrains2OP11y ago

What if there's an error in a text box or select box?

j / k navigate · click thread line to collapse