7 ms·

It's 2022 and input=date should be used instead for date pickers on the Web. https://github.com/alphagov/govuk-design-system-backlog/issues/17 https://github.c

by hendry 4y ago

It's 2022 and input=date should be used instead for date pickers on the Web. https://github.com/alphagov/govuk-design-system-backlog/issues/17 https://github.com/alphagov/govuk-design-system-backlog/issu...

dividedbyzero 4y ago
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.
makeitdouble 4y ago
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.
- oritsnile 4y ago
  On Android you can also click on the year and it should give you a grid view of years
  - bouke 4y ago
    But how is that easier than just tapping 4 numbers?
    - Tepix 4y ago
      It depends. Perhaps for blind people tapping 4 numbers isn't so easy.
  - makeitdouble 4y ago
    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.
- Tepix 4y ago
  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.
Spivak 4y ago
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.
ourcat 4y ago
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.
joelanman 4y ago
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
- Tepix 4y ago
  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.

by hendry 4y ago

dividedbyzero 4y ago

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.

makeitdouble 4y ago

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.

oritsnile 4y ago
On Android you can also click on the year and it should give you a grid view of years
- bouke 4y ago
  But how is that easier than just tapping 4 numbers?
  - Tepix 4y ago
    It depends. Perhaps for blind people tapping 4 numbers isn't so easy.
- makeitdouble 4y ago
  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.
Tepix 4y ago
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.

Spivak 4y ago

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.

ourcat 4y ago

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.

joelanman 4y ago

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

Tepix 4y ago
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.