Hacker News Reader

Comment by hendry | Hacker News Reader

It's 2022 and input=date should be used instead for date pickers on the Web.

https://github.com/alphagov/govuk-design-system-backlog/issu...

The interface looks usually nice, but input=date is horrible to manipulate in many implementations.

On iOS choosing year/month is the rolodex interface, as slow and clunky as usual, especially if you’re flipping it for 40~60 years.

On android it moves month by month at most, so it’s even funnier to swipe for decades.

I think the type=number alternative with validation + confirmation text with the month in letters is a better choice.

On Android you can also click on the year and it should give you a grid view of years

But how is that easier than just tapping 4 numbers?

It depends. Perhaps for blind people tapping 4 numbers isn't so easy.

Thanks, I didn’t realize the year on the corner was clickable.

On Pixel (android 12), it opens a scrolling list, temporarily replacing the calendar month/day view.

iOS has improved it's date picker which is precisely why you should use input=date in the first place. It may have accessibility (a11y) benefits, too.

I find that at least on iOS, selecting a birthdate through that is pretty cumbersome. It's great for dates where you can have a close-ish preset value and where day-of-week matters though.

author here, for known dates like date of birth it's still easier and faster to just type it in. Also type=date has accessibility problems and the design varies a lot, so people might get a decent experience on one browser/OS and a really poor one on another

Still, if many sites use this standard the users will be used to its UI and the vendor has a chance to improve it for everyone when people complain about it.

The problem is that the web didn't make the right separation between form fields (the composite values you submit) and the actual user facing widgets you use to produce those values.

I want to be able to do things like

    <input type=date widget="calendarpicker">
    <input type=date widget="mmddyypicker">
    <input type=date widget="mycustomcomponent">

so you're stuck with not great UX if the platform-specific picker sucks for your use-case which for this is absolutely does. If you're born in 1950 on iOS have fun spinning the year wheel for a while instead of just typing in the number.

The cross-browser support and standardisation for `input=date` (and `input=datetime`) has been notoriously poor for years. It's still only listed as 'partially' supported on some browsers on caniuse.

That's why so many people roll their own.

Reply on news.ycombinator.com