Hacker News Reader

Comment by kmoser | Hacker News Reader

What do you mean? Most browsers support <input type="date"> natively just fine.

> What do you mean? Most browsers support <input type="date"> natively just fine.

The `<input type=datetime-local>` on FF has a broken time-picker[1], has always been broken, and there are no plans to ever fix it, ever.

[1] In that it will let you pick a date, but not a time - the time must be manually typed into the input!

What's hilarious is they do have UI for it in about:config "dom.forms.datetime.timepicker". It makes me so angry that it's not on by default. It works fine!

On Android, the date picker widget is fiddly to use for selecting distant dates, like date of birth. Not impossible but requires many many taps.

That's an implementation issue, not a specification issue. The specification just suggests the user is shown a date picker.

You’re technically right but that doesn’t matter.

That you’re correctly using html forms won’t quickly lead to browser improvements.. so the result is that users will hate your forms. Users/your customer might possibly even think that you’re to blame, and not $browserVendor.

I’ll go one further and say that the customers are absolutely justified to blame the developer instead of the browser. If a developer knowingly chooses a built-in form control whose common implementations are bad for their users, how are they not at fault for the resulting experience?

“This site only uses functionality provided by the HTML spec” is not a useful goal in and of itself. Using the right tool for the job, which might be JavaScript, is always more important.

It doesn't really matter whose fault it is, the end result is that your users have bad experience on your website.

I've never had a problem with that myself. I guess people don't know you cab tap the year in the date picker to quickly go back a bunch of years?

Reply on news.ycombinator.com