> Actually the Firefox and Chrome date pickers look... exactly the same
They look nothing alike though.
Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).
Hmm I'm on a macbook. I assumed the component was a browser implementation, but maybe MacOS somehow overrides that?
Would you mind providing a screenshot of how it looks on a different OS?
Edit: I've google around and I'm only finding UI that looks the same so now I'm very curious about what UI you're seeing that looks different. What browser and OS are you on if you don't mind me asking?
Both different, both slightly better (because it's clearer the year field is a drop-down) than safari from TFA. I find FF to be the best usability-wise
Ah I see. So the issue is basically just that on Safari mobile the arrow points to the right instead of downwards. That seems to be the only difference between Safari and Chrome. It seems Chrome's mobile implementation is worse on every front here (second in pic):
> Ah I see. So the issue is basically just that on Safari mobile the arrow points to the right instead of downwards
The "correct" direction for mobile safari would actually be left, IMHO. Mac and iOS (as well as the iPod and watch) use navigator patterns heavily, where left to right you have a stack of screens with progressively more detail. So it would make sense to have a MMYYYY view, which opens into a monthly calendar, which goes to a time of day.
"Correct" in quotes though because the date/time information is directly manipulatable at every level (it is a picker, after all). Turns out the best level to start at and affordances to pick a date in particular differ by use case.
For instance, the iOS Calendar app has a years view, but it shows a full yearly calendar, one per screen, and makes you swipe 15 pages up to see if you had any calendar entries from the first iPhone.
This makes sense from a calendar point of view, because it is far more common to want to navigate within the same year or previous year than to want to visit your calendar from 15 years ago.
It would be an absolutely terrible interface for seniors to enter their birthdate; far worse than the default here in fact.
If you enter a birthdate in the Contacts app, you get the "three tumbler" interface (for Gregorian calendars, at least) - months, days, and years, presumably in a localized order with localized text.
It is somewhat unfortunate they didn't just stick with this for the iOS Safari interface, as form input entry already expects that a good chunk of screen real estate will disappear for the keyboard. Instead, they went with a floating picker because thats what most websites currently implement (via javascript)
The Safari from the OP is on mobile. Chrome and Firefox on Android are arguably even worse than Mobile Safari since they don't even have the little affordance arrow https://i.imgur.com/4w8IvO8.png
Safari on desktop is pretty bad but at least it leaves the text fields there for you to just type in https://i.imgur.com/NSRvPcm.png
Agreed. Safari's mobile implementation is better than Chrome's. Firefox feels like the only one that got it "right" but even then I think many seniors would still not realized they could navigate by year
Except that the second and third ones are clearly awful, as there really is no way to dig into the month/year for faster manipulation (at least not one that's readily apparent).
From left to right: Chrome desktop, Chrome mobile, Safari desktop, Safari mobile, and Firefox desktop
Yes both Chrome and Safari's implementations suck, but I feel like seniors would have a hard time with pretty much all of these. Firefox is clearly the winner here, but I'd imagine would still trip many seniors up
The ones with editable text input fields are all desktop browsers (1 is Chrome, 3 is Safari and I think the last one is Firefox) and the ones without them are mobile (2 is Chrome 4 is Safari)
I haven't tried it, but I imagine you can manually override an `<input>`'s onFocus to not call `e.target.showPicker()` when it's focused on. This would likely allow users to keyboard enter an amount instead
Might be annoying for users that actually know how to use and prefer the picker however.
They look nothing alike though.
Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).