Safari's date-picker is the cause of 1/3 of our customer support issues | Hacker News Reader

Safari's date-picker is the cause of 1/3 of our customer support issues

gist.github.com

565 pointsrobertakarobin346 comments

So I'm not the only one.

It's not just limited to Safari. Any and every date picker that doesn't allow text input of the date is ridiculous, those of you that design these things that call yourselves designers should find a new career path, I recommend selling cologne out of your trunk at a gas station, and if you're involved in this blatant and hostile devolution of interface I hate your guts. This particular one is my number one hated trend in UX, by a high margin. It is the most absurd set of design decisions I have ever seen, I can't see how it would not be malicious, it shows disdain for your users and you should be ashamed of yourselves. Fix this one and then we can talk about the others.

I think it's just Chrome and Safari's mobile versions that "don't allow" text input. And they actually do allow it. But most users don't have a keyboard hooked up to their phones

The issue is that with mobile something has to pop up. So browsers need to make the decision between an onscreen keyboard or the built in pickers (this holds for color pickers as well)

If web developers don't want any of this, they could always just use `type="text"` instead of `type="date"`, but this leads to other accessibility issues and means you have to write a ton more code for proper validation

Yeah, but from a user perspective text is superior to date. I don't even know a non technical person that doesn't curse under their breath when a date picker pops up.

A simple "date (DD/MM/YYYY)" or similar format above a text field is a blessing these days, but I'll take anything over a date picker. A good date picker would let the year drop down somewhere, show calendar view, and allow text input of the date. That's the minimum requirements, a month drop down would be nice too. Sometimes I run into date pickers that have some unintuitive way to page years, one click at a time of course, and while I dislike that, at least I can move back by a year, it doesnt ruin my day. Imagine someone deciding that to input the exact time of something you'd select a drop down containing Unix timestamps, one option for each second, that's probably the only thing I can think of that would be more frustrating and senseless than the current state of affairs, and even then perhaps not because at least it's a dropdown you can scroll on. Literally a scrolling dropdown of all dates back to 01/01/1900 would be a superior UX to the current common date picker design.

> Yeah, but from a user perspective text is superior to date

Hmm I'm not sure if that's always true for mobile users (the subject of this post). Given any default starting date, I can enter in my DOB in:

- 1 tap

- 2 swipes

- another tap

If I was instead presented a keyboard I'd have to make 8 taps. 9 if I count having to switch from abc to 123. And this is under the assumption that the text field has an input mask built-in so I don't manually have to type the separators. If I did have to type those this would be bumped up to 11 taps

I agree with you on desktop though. But the thing is, that already is the way it works on desktop. You can ignore the calendar picker and just type it in directly. It actually works that way on mobile too, but most people don't have a keyboard plugged into their phones

> Given any default starting date, I can enter in my DOB in: - 1 tap - 2 swipes - another tap

===================

How? Reading this, I can’t imagine any scenario where I could enter a specific date on mobile with 4 interactions.

well I guess 5

1. Tap the year-month 2. Swipe to your year 3. Swipe to your year 4. Hit the checkmark 5. Tap the day of the month

Lol the crux here is "swipe to your year". This could be 100 swipes or more. This should not be the standard way you select a number from a sequence of numbers, it is insanity. But even that is better than the common approach which only let's you swipe months.

I've seen it on desktop as well as mobile, I've seen it implemented in JS and not just an HTML5 problem, so there are no excuses, but on the topic of mobile, I have a keyboard that pops up just as quickly as a calendar view, even with the argument that most people prefer to use their phones graphically and spatially (which I don't entirely buy), there's no reason to prevent me from typing in a 4 to 8 digit number if I want to, none. UX design is not just an issue of number of taps, it's an issue of cognitive load required for interaction also, both considerations can introduce or reduce friction, and in the case of a commonly implemented date picker you have artificially introduced friction from both of those considerations, it's a devolution in design, plain and simple.

> I don't even know a non technical person that doesn't curse under their breath when a date picker pops up.

I used to designed software for factory automation and every time there’s dates involved the datepicker is always an explicit requirement. I tried to ignore that once (they were more annoying to implement back in the days) and the plain text field didn’t even get past the first meeting. I guess “non technical person” is not as coherent a group as you may imagine.

The issue is that with mobile something has to pop up. So browsers need to make the decision

Back in the day we had buttons in inputs, so a user could either click on white to enter the text or click on a button to see a picker/something. Same goes for type-or-choose comboboxes, search-or-choose object picker fields, type-or-calculate numeric fields and so on.

In addition to that, specifically for date fields in inhouse systems I’ve often added a popup button with most obvious starters. E.g. some reports assume days around today and some are mostly month-oriented, so a popup contains “today (<date>)”, “yesterday”, “start/end of week/month/quarter”, some combination of these. And also “+/- <unit>” buttons to quickly adjust a period in case they changed their mind. Users were happy. Good luck choosing a previous quarter and narrowing into it with these modern ui abominations.

It’s not a mobile issue, it’s an issue with stupid decisions around “stupid” users who still don’t get it, as all our occasional tests on eldery show. These ui patterns are designed for someone who never existed irl.

And what’s worse, these uis are not forced to use by those very designers. We could see a great improvement if they were forced to sensibly pick 50 random dates and other fields before collecting their paycheck.

Almost every date picker I've used is terrible. If you are reading this and are responsible for adding a datepicker, please, please, please do at least the following:

1. There should be a textbox allowing me to type a human-readable date/time (e.g. "monday 5pm" or "july 7, 2015").

2. The textbox should be selected and ready to type into as soon as the datepicker is opened

3. There should be a short list of previously-typed dates because often, for a given date in the UI, the same date is used multiple times in quick succession

4. There should be a typical month view with days of the week visible, in case I'm on mobile

5. The current date should be highlighted on the month view.

6. I should be able to pick the month and the year in at most two taps each (i.e. dropdown for each), no matter how far back in time I need to go.

Shameless plug: we recently implemented an exceptional date picker on momentcrm.com because of how frustrated we were with the default browser experience.

In my web apps, I make dates text boxes that can handle inputs like “next Thursday”, “Monday at 5p”, etc by running the inputs through https://github.com/mojombo/chronic

I like the idea of inputs being able to make sense of as wide of a variety or formats as possible.

For number inputs I’d like to build into Rails something that can handle basic math expressions. For example, a person can enter “120 / 2” in an input and get 60. This is useful for expense apps where you need to expense half of something.

If folks are interested, I can open source these bits. I’d like to expand them as much as possible to handle an even wider variety of inputs.

Chronic is an awesome date library, agreed.

That's a cool library. I note that WolframAlpha handles this type of stuff readily. Does anyone ever bundle Wolfram products into theirs to handle natural language type things? I'm not immediately sure of the licensing framework, but it would seem nice to be able to do that.

Edit: It seems that WolframAlpha does have an HTTP API.

https://products.wolframalpha.com/api/documentation

I'm curious if anyone has used it. It costs but it could save an immense amount of time.

Embedding wolframalpha is probably overkill, when all you need is simply a small arithmetic expression parser and to understand expressions like "next month" or "2 days ago", which even tools like GNU date support.

For dates, probably, but I was more curious about other natural language use cases.

Hat tip that you mention GNU date. I am surprised each time I use that feature and it manages to produce the date that I wanted.

So you do you handle every language or just English. Can I write 来週の木曜日? or "hier" etc...

Some of these are really great ideas! But I think they should be relegated to an external library or perhaps a web component. The issue here is this is the HTML datepicker. The picker itself isn't well-defined but things like being able to type in human-readable data/time and having it interpret that would likely conflict with the HTML standards already defined and be extremely difficult to define further. Not to mention you could only really do something like that on desktop and the issues pointed out in the post are dealing with mobile date pickers

>> Almost every date picker I've used is terrible.

If you think date pickers are bad, you'll love time pickers, e.g. https://vuetifyjs.com/en/components/time-pickers/

I quite like the iOS time picker, but agree the analogue clock style that I think Android popularised is awful. The iOS one also gives a number keypad if you tap the wheels so you can enter that way if you prefer. It’s a shame they don’t do anything similar for dates.

I've never see the analog style clock one before, wow that is garbage. I'm not a fan of the iOS style time 'reels' either, but like you say, at least it opens a keypad if you click on them.

Those aren't so bad, they're reasonably intuitive to anyone who knows how to read an analog clock, and though they're easily fat fingered, you do one click for hour, one for minute and AM/PM in the non 24h versions. Imagine a scrolling time picker where you couldn't scroll the hours, only the minutes. That's what common date pickers are like.

To break down why this picker is bad, here are several UX snags I immediately ran into.

1) It was not obvious how to set minutes, and I spent several seconds trying to get the hour hand to go in between hours.

2) When I let go and it snapped to minutes, it was not obvious to me how to go back and change the hour I had just input incorrectly. Then after I input minutes I expected it to jump back to hours but it didn’t. This is especially bad if your first interaction is a single touch rather than a press and hold, as it will jump with a wrong input and no obvious way to go back before you can even process how the interface works.

3) I have to look at different areas at the same time to select a time. My finger is trying to scroll a circle (where btw my finger covers the number), but I have to look above to see what the input is.

4) The above was even trickier in the minutes inputs, since there were not markings for sub-5 minutes.

5) It was not obvious that the top bar was clickable as an input area to select am/pm, especially since clicking the top bar would not otherwise allow you to input the time.

6) It’s not obvious with the switch to minutes / seconds that the units have switched. Need some representation of this on the clock face itself.

Some major ticks on all inputs and minor ticks that pop up on the minutes input would help a lot with 1, 4, and 6. Could be subtle markings, but would help quite a bit imo. But really this didn’t need to be anything other than a simple text input.

Very nice site. I was clicking around trying to find a sample of your date-picker and noticed that the "Free Courses" link is not working properly. I believe it is treated as a relative link as it takes me to:

https://www.momentcrm.com/https://academy.momentcrm.com/

I'm still perplexed that this isnt how every website works.

The absolute worst are date pickers that grey out unbookable dates to look like past dates and default to one week from now, leading me to believe, if I'm not careful, that Im booking a ticket for today.

Seemingly no website that lets you book things has sensible date UX.

In your (1) case, how do you handle input that is m/d/y vs d/m/y - there are cases where cannot identify which convention has been used.

> there are cases where cannot identify which convention has been used

You could always just ask them. "I'm sorry but we had trouble parsing your date. Please indicate the correct date:

_ Saturday the 12th of March, 2032

_ Wednesday the 3rd of December, 2032

_ Neither, let me choose again.

how about placeholder="mm/dd/yy" or placeholder="dd/mm/yy"?

Also, I’ve repeatedly come across date fields that force me to enter the month in two digits, i.e. 01 for January. What’s up with that?

That's the default in Germany (and Europe?). Writing out the month is somewhat rare, although it does happen.

I think GP meant that it's two digits instead of one (you have to type 01, not 1).

I’ve seen that, but I’m ok with it. I just assume it’s much easier to parse/check the entry if there’s a full 8 digits (mmddyyyy).

The problem being, the date picker is already a (single) input field. Having multiple input fields for what is already an input field somewhat defeats the purpose.

This doesn't address the real problem, though, which is IMHO that a calendar-like presentation doesn't lend itself easily to numeric date input/selection, especially, if it's about a date outside the current month. (E.g., a 3-column list view, which could be operated both by mouse/touch and keyboard input, may serve the purpose a bit better. Safari mobile could even style them rolodex-like… Which is, BTW, how it used to work on Safari mobile, before they switched to the unified style.)

What should really happen is putting these "designers" into the helpdesk seat. Or at the very least have them observe how people use their designs and they are not allowed to interfere. It will be a painful lesson for them. But as long as these things don't happen, we will be stuck with this major suckage that is modern UI.

I miss the old days when Apple and Microsoft had teams of people user testing every new feature instead of just following the whims of their designers

I remember the time when we would pay for software and expected quality in return. Nowadays it's either free (sponsored by ads and or surveillance) or bundled with hardware to be abandoned when the manufacturer wants money again.

I wonder if you could actually rather quantify date related errors by analytics. I actually booked the wrong return flight once because the date picking logic was too intelligent for me. There should be many signals pointing to this.

> What should really happen is putting these "designers" into the helpdesk seat. Or at the very least have them observe how people use their designs and they are not allowed to interfere.

The fact that this isn't natural standard practice speaks volumes to the current state of """UI design""".

My personal experience is that a significant number would simply blame the users.

Gut reaction: Designers blaming a serious percentage of users are obviously working for a company with users who are a poor match for their skills. Management should "encourage" them to move on, to other companies, whose users would let them really shine.

I call this the gnome affect.

Can't seem to find this when I search, care to elaborate?

At a certain point companies employ "experimentation" (mainly A/B tests) to do exactly this. They measure dropoff and other things, and have targets, e.g., "acceptable dropoff" or whatever they might term it internally. That small amount of user loss (fraction of a percent to a few percent depending on feature/daily usage/other metric) due to a design is considered acceptable: not that they don't care, it's just not considered impactful enough to the business to matter.

Any user who designs something like this that doesn't realize the number of mouse clicks needed to navigate this interface doesn't need to be a designer. Helpdesk experience won't save them, they're either bottom of the barrel incompetent or outright malicious. I could understand if it were something more complicated, but there's no excuse for this stuff with date pickers.

This is called dogfooding, and developers have to do it all the time to make sure functionality works before deploy.

I feel like designers do this minimally, or can get away with more functionality breakage or poor UX because they can make things look slick.

Literally yesterday I encountered the date picker that didn't allow to manually change the value and didn't display whole calendar properly, with days in 5 and 6 row either invisible or not reacting to selection. And when it is obligatory event date field in insurance claim system, it is hard to apply Hanlon's razor.

Every non-typed input field should be able to be manually edited with a keyboard.

Thank you, so much for pointing this out so succinctly. I'm a 59 year old engineer (originally electrical, but got a bit into software engineering and have been doing enterprise network and security design deployments for the last 30 years). With very aged parents and a mother-in-law all over 85, I have more and more become aware of the absolutely horrible user interfaces that abound all over the place. Smart phone and web based offerings to do basic tasks of interacting with government, bank, shopping and similar services literally are unusable in many if not most cases for most over 70. ( My loved ones all have used PCs since the 1990s). Banners blot huge chunks of screen real estate, metaphors for selection and entry of data change within a services pages let alone between them, active screen objects may as well be hidden.

When I retire from full-time work, I almost feel like I should make it my mission to front up to these organisations and "pretend" I'm their typical user or customer that they are not serving very well at all, and put a rocket up them demanding why with all their technical and designer resources they should have at their disposal why they can't provide a useful and satisfying user experience.

If you created a document of design guidelines that you could simply link in response to posts like this, it might actually go a long way. I would be glad to read about what you’ve learned about user interfaces and the considerations necessary to include the elderly with regards to accessibility, and would certainly bookmark it / utilize it / consider it when creating UI. I’d imagine others would also.

If anyone else has such a thing, I would encourage you to share.

The original Human Interface Guidelines from Apple were the golden example of good design. Research-based concrete rules for everything (including designing custom UI elements), resulting in a coherent and useable GUI UX.

> Smart phone and web based offerings to do basic tasks of interacting with government, bank, shopping and similar services literally are unusable in many if not most cases for most over 70.

been working on the web for ~20 years now. the amount of debugging, switching devices, just general hacks i need to do in order to interact with certain websites is a bit crazy:

- open my desktop browser

- open a specific browser

- disable all extensions

- open a new private tab

- inspect element with the dev tools

- js breakpoints and fixing minified js code on the fly

- removing or adding css

- allow location/camera/etc permissions

all so that i can press a button on a website :))

i’ve always worked in small teams. and we always tested on all the browsers, on all the devices. manually and automatically. and this is every time we deployed.

how some of these broken websites get to see the light of day is just unreal.

Are these websites big, or small local things?

huge, big, small, all of them, startup, fortune 500, international bank, local government services. errors occur due to a huge number of reasons: ISPs, lack of testing, connection issues, outdated tech, cdns, certificates, javascript, js minifiers, assumptions made by devs/po’s. basically the web is so huge and complex that websites will fail in any random number of ways.

Absolutely. I would suggest another kind of job for this kind of "designers".

Programmers and UI designers should observe there two common use cases:

1: dates close to the current date, such as flight dates, meetings, delivery dates. 2: birth dates and similar (wedding date, start of employment), often a long time ago.

For “near future” dates, date pickers are somewhat handy because you can see the day of the week, and glance the number of days compared to other dates.

For date of birth, date pickers are useless. You don’t need to pick anything, you will just know it by heart in most cases and you can type it fast enough.

Programmers like date pickers, because you can’t choose nonexistent dates, you can’t confuse day/month number, and you can’t enter ambiguous 2 digit years. And they like consistency, so the same design is used for all use cases.

Please realize that consistency != usability.

As one of the comments on that thread points out, every desktop browser seems to allow text input, and every mobile browser is obtuse like iOS Safari.

This is not the case, I have used date pickers on desktop that were equally atrocious. Granted they were implemented in JS, so not a problem with the browser rendering but still, if we are talking about design here, the designers of those interactive elements need a stern talking to as well.

In the 21st century, every date picker should be able to accept both mouse and keyboard input and be very permissive about what is allowed.

There should be a text box I can just type "January 1 2022" or "2022-1-1" or "4/20/69" into, and it just figures it out (with a disambiguation dialog and 'save as default' popped if I feed it something ambiguous).

But that’s exactly the problem. A good website employs an “international-first” approach. As such, having such lenient formatting can be a compounding problem pretty quickly as you’re trying to accommodate all types of formatting dates for all languages and regions.

Imo, the site to plainly and explicitly require an exact type of date formatting. It’s very easy to validate and they can even help with formatting.

The site shouldn't have to do any of that. Ideally, the client-side date picker should handle it (it has the context to know user preference on whether "4-1-69" means January 4 or April 1, and the context to know to ask for clarification if it doesn't know the user's preference yet).

Another similar input problem: when you can't manually type the country code in the phone field and have to scroll through the a dropdown menu just to choose the right set of numbers. Even if you know it.

It's called false simplicity. It looks easy but is actually hard to use. It's like Microsoft's ribbon design change. It hides a bunch of elements but made it difficult to figure out and click through.

Date widgets are almost universally bad. Most I encounter are unintuitive or outright buggy.

However, OP complaining about usability and the providing three text fields with the MM and DD being placeholders is terrible. Normally placeholder-only labels are a bad idea, but this is especially true when the month and day fields have different order depending on the region. The moment you've got [1] [4] [1980], you no longer know which is month and which is day.

And do they swap these placeholders and entered values if you change the country from US to an EU country?

The lack of progress in the tech world in making consistent user interface standards is disappointing. We should not be still struggling with these topics (and as users we should not be suffering). Tax time, trying to fetch reports from banks/exchanges is one of the worst recurring experiences...

Actually the Firefox and Chrome date pickers look... exactly the same

I don't think this is so much a problem of UI not being consistent as us just not providing resources to help elderly navigate the web better.

Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache

  <input type="date" value="1960-01-01" />

Edit: ok, not "exactly" the same but functionally very similar. Or at least they'd have the exact problems pointed out in the post. See for yourself:

FF: https://blog.nightly.mozilla.org/files/2017/06/input_date_ca...

comparison: https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...

> Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache

I'm not sure how that really helps? Moving multiple years is still going to be a huge pain, so you're only really saving people who have a birthdate in or very close to that same year.

Right then other things they could do:

- provide some helpful text explaining to users how to switch between years

- use an external library with a custom date picker

The reason why I wouldn't recommend the approach they went with is because there's all sorts of aria-related properties and semantic meaning for screen readers that type="date" carries. This is especially relevant for the target audience they're talking about. I guess the third option is

- what they did but actually try it with a screenreader yourself. Make sure your aria labels make sense and is navigable for both keyboards and screenreaders (two separate issues). Also make sure you're replicating the validation logic that type="date" gives us for free. Basically replicate all the complex HTML5 logic and semantics

Such text will likely not be read by many. I think I will read it as I am generally a reader of how-to or help files to get a better idea of features. However the rest of my family you would need to point out the explanation text and likely also 'force' them to read it. They much rather tap around in the hope for the desired outcome.

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

Windows:

Firefox https://i.imgur.com/j8djrhN.png

Chrome https://i.imgur.com/mmBInsQ.png

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

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

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):

https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...

I do think Firefox does it best if the whole issue here is just that the year-month picker needs to more obviously look like a drop-down

I agree that would be an improvement, but tbh it doesn't seem substantial enough to fully prevent the issue that the seniors in the OP were facing

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

I found this comparison from a Chrome blogpost:

https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...

I'm really struggling to see how any of these alternative implementations are an improvement as they seem functionally exactly the same.

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

The awful ones are both the mobile browsers, the others are desktop browsers.

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

Some of those have editable text input fields. That leaves people the choice of entering the date manually or trying yo navigate the picker UI.

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)

Yes all the desktop ones have editable text.

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.

> Actually the Firefox and Chrome date pickers look... exactly the same

It does not seem that most websites use the built-in date pickers. I've seen dozens of different date pickers all while using Firefox. This is the key problem.

At least if everyone used the browser native date picker, it would be consistent within that browser. Then we could debate about which browser had the better one (and maybe standardize).

Or 1959-12-31, so nobody has to guess if it is yyyy-MM-dd or yyyy-dd-MM

>And do they swap these placeholders and entered values if you change the country from US to an EU country?

The solution is to use words instead of numbers for Month. I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Etc and not 01, 02 , 03.

And always show 4 digit for years as YYYY.

> I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March

Except for the vast majority of the world that doesn't use the English language.

Except that i18n is a thing in this modern world of whiz-bang UI toolkits.

Note that it i18n isn't implemented correctly by any of the browser date pickers. Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive. So for anybody wanting to interact with both US sites and local sites (presumably quite a few people on the planet), they'll never be able to have appropriate browser date controls - either they get to have US controls on local sites, or local controls on US sites - and both are quite confusing, especially before you open the date control. Unopened date controls just show the client-culture-localized date, so if that doesn't match the site culture... it's going to be a mess.

Surely date widgets that behave subtly different depending on what website you’re currently visiting would be more confusing.

> Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive.

For what it’s worth, whenever I have to write a date on an American-authored form, I use YYYY-MM-DD, as do all my colleagues.

Definitely not, from experience. Browser widgets need to be context sensitive, not client sensitive. There are (at least!) two simple reasons to see that: firstly, non-browser site provided controls are more common, and those are context sensitive, so it's quite unusual and surprising when a date-widget suddenly is not context sensitive merely because it's using the browser default. Secondly, date controls display dates even when unopened, and in that mode - the default, initial mode upon page load - they look like plain text with some mild styling to indicate interactivity. Dates in plain text should behave like other dates in plain text - i.e. context-sensitively.

To reiterate, there is an obvious, correct implementation here: let the site specify the content culture much like it does the language, and fall back to the user's choice when unspecified. The spec is asking for user confusion and data corruption as-is, which contributes to why usage of date controls remains fairly low.

It’s all fun and games until you end up with January, December, 20December because the dev only tested in the second half of the current year’s month.

You could also do both and have the placeholder smoothly transition between being a placeholder vs being a label. Not to self-plug but here's an example I made myself

https://dontplaywithculi.netlify.app/readlater

(it doesn't do anything, just a UI experiment)

>And always show 4 digit for years as YYYY.

Not everyone uses the Julian calendar, or even 4-digit years. Here in Japan, this is year 4 of the Reiwa era, so you need a year picker that lets you choose the correct era (Reiwa, Showa, etc.) and then the year of that era, and of course the number of permissible years per era differs greatly. (The era reflects an emperor's term, so when we get a new emperor, we start a new era.) Then, just because this system is such a PITA and anything international doesn't use it (but everything government-related does), we need a converter that lets you convert between the Japanese standard and the Julian calendar.

> Not everyone uses the Julian calendar

Almost nobody does. You probably mean the Gregorian calendar.

Yep, sorry. Too late to edit it now though.

I really can't believe that Japanese users don't use the Gregorian calendar for most of their activity.

I wouldn't say the Japanese calendar is used for "most" activity. As far as I can tell, the Japanese calendar is certainly used for things like government forms, but for non-government stuff, not so much. If I buy tickets for something online, for instance, the web form asks for my birthdate using the normal Gregorian calendar year. Even the government stuff is a mix; my residence card shows my birthdate and card expiration date with the Gregorian year.

> The moment you've got [1] [4] [1980], you no longer know which is month and which is day.

The one true date format is YYYY-MM-DD

I have a special hate for the native browser controls when it comes to date ordering. Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. It's normal therefore to see dates in a format that's appropriate in context - a us news article might use a US format; others will use a different format that makes sense in context.

Yet that's not how browser controls work - browser controls for all major browsers always use the client's date formatting settings when displaying dates (once popped up it's usually obvious which is which). And that just makes them pretty much unusable; it means outside of the US you will have dates in text using 1 format, whereas browser controls use a different one. That's... completely unusable. How all three of the major browser manufacturers managed to agree on this particularly hostile design is beyond me.

> Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format.

What is odd about it other than being different and not being immediately lexically sortable in file names?

Edit: It's an honest question. People and context help determine what you're wanting out of a date, so I am curious what is viewed odd about the U.S. format aside from it being not what your country uses or what the ISO standard is,

The middle-endianness.

That describes it, but what is odd?

What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, the day clarifies the particulars, and the year locks down the date but it is almost always known in the given context. In my opinion, there is the one true format for data formatting and text representation (the ISO standard), but each of the various permutations do have their use cases where they shine. For normal dates, all three components are needed, but it is usually nice to know the month, then the day, and then the year is there just to be clear. Knowing the day gives me little information until I have the month, whereas getting the month first gives me more information, where sometimes I can even ignore the day.

> What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, [...]

In my experience, the thing which is the most important/relevant in most situations is the day of month. People often say things like "dia 10" when asked when something is going to happen; that means in context the 10th of the current month if today is the 9th or earlier, or the 10th of the next month if today is the 11th or later. The month is added only when necessary, like "dia 10 de fevereiro" (just "dia 10" today would mean the 10th of January).

All this works in British English just the same as it works in Spanish etc.

When are we back at work? On the second. Then go-live is on the fifth of March. (Normally 5 March or 5th March when written.)

I am not persuaded that there is any hierarchy of importance here, let alone that there is a preferred one. Any wrong date is the wrong date.

Regardless of whether it’s useful, middle-endianness itself is odd.

Truly a bizzare argument that only gets harder to understand every time I hear it. Whether the day, month or year is most important changes per every case.

Are you telling me if you had file cabinets for the last 50 years, and you had to get a specific file Nov 1992, you would rather sort first and get all the files marked "November", and then sort through those 50 to get to the 1992 November? Surely one would reduce down to the year - 1992 - first, and then to the month.

Same for alphabetical ordering, a data list ordered by logname-MMDDYYYY.log alphabetically wouldnt be chronological order - YYYYMMDD or DDMMYYYY would.

Month is primary in some cases sure, but I think year and day endian are primary in many others - plus have the above sorting and ordering benefits.

To be clear, I said

> each of the various permutations do have their use cases where they shine

As others have said, it's the middle-endianness itself which is weird. Also, if you're going to write the whole date anyhow, I don't think it makes a huge amount of sense to describe any part of it as "more important" to the extent that it deserves re-ordering a date.

The evolution of the US ordering feels (I might be wrong!) similar to how spoken numbers are little endian from 11 to 19, yet big endian from 21 to 99. Some languages are even worse in this regard; but regardless, they're unhelpful historical artifacts that we learn to live with, not actually helpful, well-thought-out, or even merely irrelevant. Notably there are considerable differences between how quickly children learn maths in different languages, and digit ordering may contribute (of course other cultural factors may contribute too). I wouldn't be surprised if date ordering too is similarly a small but real drag on learning.

It's "odd" for a person who is used to saying "third november" and not "november third", i.e the order is reversed even there.

A spoken language full date format for me would be like "third november 2022". That, in either in english or in my native language.

I don't know how circular this argument is (does the spoken form come from a written form of the date?). But this is what makes it odd, that in spoken form I, for example, am used to saying the date first but the "odd" date format writes the month first.

That’s the type of thing I was looking for. Thanks.

I’m curious about the circular reasoning as well, as the same would hold true for both preferences.

Do you mind sharing what language you speak where the day is most often said first? It sometimes is said that way in English, but not as often as the other way around. It’s usually said that way when the day carries higher importance than normal. Like the 4th of July or something.

Sure, Swedish. I prefer day first in English as well as I understand it it's accepted and commonly used (British English).

The languages I know how to say it in are all closely related to Swedish but they agree. And then Spanish uses day first too.

This is the case for most Slavic languages.

Can you elaborate on what you mean by date ordering?

I suppose that the ordering of dates is independent of locale.

The locale rules for the date format are simple: the DOM value property of the field is a string in YYYY-MM-DD format, independent of locale.

The date display format and what the text input accepts depend on browser locale.

Conversion happens automatically and the text input is shown in a way that indicates locale on desktop, least I remember (e.g. dots for European format, slashes for US). If a user enters "1.5.2011" in a browser with German locale, HTMLInputElement.value would be the string "2011-05-01" (invisible to the user).

I honestly can't think of any better choices, the only thing missing is some attribute to eplicitly control display locale. Which is probably by design, as it would be abused to override system/browser locale and create confusion.

I once replaced a Vue date picker library in a web app with native date inputs for UX reasons (e.g. typable dates, reliable visibility of the picker when fields are near window borders, mobile UI...) and users were reportedly happy with that.

Admittedly, it was mainly a desktop app.

So, long story short: the only problem I see here is the mobile modal date picker UX. And thankfully, it can be improved in the future because it's part of the OS and not controlled by the website.

> Can you elaborate on what you mean by date ordering?

day/month/year

month/day/year

year/month/day

year/day/month

The order of the numbers an be problematic. For example, 01/01/01 could be 1 Jan 2001, Jan 1 2001, 01 1 jan, or 01 jan 1.

Would rather not do the april fools example. Or the pi day example.

All of this is thankfully resolved by the spec choice to stick to a specific ISO string format for the value property.

You are talking about locale-dependent formats - which is why the value property of the input element conforms to ISO 8601 YYYY-MM-DD and guarantees that the values are predictably sortable.

There is no other meaningful ordering of dates other than sorting chronologically.

HTMLInputElement with type=date honestly does everything right given the constraints.

As said, this post is a valid complaint about mobile native UI, no less no more.

The problem isn't the machine-readable encoding that indeed happens to use the ISO YMD ordering, its that you can have a site that's in language/culture X, which includes dates related to whatever events or moments are relevant, but also includes a form with a date-field ordering that is _different_ from that of the text and possibly date fields, and _different_ from the convention in language/culture X.

Actual human language is context sensitive. The user's date formatting preference is almost a non-sequitur even as a concept. People fundamentally can't pick whatever date formatting they want in general-purpose content; they'll need to be able to understand whatever is the norm in that context. And in most contexts while there are various date forms, they're usually not (problematically) ambiguous. As long as a user stays within one date-formatting bubble, that's fine, but it just works really poorly if a user does not. Within an application that's primarily concerned with dates and in which every date is a specially typed value, like say a calendar - sure, date formatting preferences are feasible. That however describes a rather small fraction of the overall web. And the textual, machine-comprehensible hypertext web itself, while eating the world, is itself still only part of culture; dates are visible in videos, images, books, magazines, etc - and they make sense in those contexts _in context_ - i.e. _not_ using the client's date formatting preferences.

If a user's date-formatting preferences were to really have meaning on the web, you'd need to ensure that even dates in plain text or written summaries satisfy that formatting, and hope that videos and images rarely are mixed with such text. But that's just not the norm, and likely completely impractical; it'll never happen, especially not given the reality that many dates are manually written by humans without any markup at all. And where software tries to "fix" that - well, you get disasters like Excel, which is notorious for causing insidious data-corruption by trying to guess data-types in pretty creative and unhelpful ways.

In practice that's not what sites _actually_ do. They either have really simplistic date handling, in which case date controls can be confusing but rare enough that it's not hugely impactful, _or_ they use custom date controls (the actual norm). And that makes browser date controls _even_ worse, because those will then unpredictably not use the context culture, but instead the client's culture - unlike most sites, which don't use input type=date as far as I can tell.

The correct solution would be to allow a site to specify the site's culture and formatting settings, much like language can be specified. And if none is specified: sure, fall back to the user's date preference.

When does this problem come up? I don't see much combination of dates in the page's content in addition to simultaneously submitting a form with date input.

The month input could be a drop-down with a three-letter abbreviation for the month. That would eliminate the need for a label.

Even if safari had the greatest date picker ever conceived, don't use date pickers for date of births. They will never be better or faster than typing your DOB. Pickers are best for choosing dates that aren't known ahead of time, or where you need to know how a date relates to week days / week numbers etc.

The proposed solution of using number inputs is also not great, since they have a host of accessibility issues [0] You want a regular text input with inputmode="numeric" and a pattern attr. This will give the correct numeric keyboard on mobile, and work just as well in desktop, without any of the associated issues.

I've built several date pickers, I know how hard they can be to get right. But they shouldn't bbw blindly used for any date value, they should be a deliberate choice

[0] https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...

> Even if safari had the greatest date picker ever conceived, don't use date pickers for date of births. They will never be better or faster than typing your DOB. Pickers are best for choosing dates that aren't known ahead of time, or where you need to know how a date relates to week days / week numbers etc.

Interestingly the old iOS datepicker was actually pretty good for DOBs: the old picker just gave you three scrollwheels with the year, month, and day (possibly in your locale order), scrolling through the years was a very quick thing: just flick the years wheel and off it goes. A touch finnicky to adjust, and maybe not great for close picks because of the lack of context.

The issue here is the "new" (iOS14) calendar-based pickers, which give you, well, a calendar, and hides the quick month/year direct selection behind a dropdown (and as the essay notes without a day wheel, so now you have to open the year/month selector, jump to the right one, confirm that, then select the actual right day on the calendar view).

Especially given the flat design language as it's really not obvious the month/year and their arrow is an active dropdown.

This is a curse of web design - you have to guess if it's clickable. You're not allowed to have boxes, or lines, or raised buttons. It's almost a dark pattern. It seems to be a holdover from mobile, where unmarked buttons were a thing, but the buttons were bigger and the UIs simpler. Now they've migrated to busier interfaces and become smaller.

Date pickers are terrible if not near the current date. Ones for long-term data sets where you set the start and end date are a huge pain. Like getting inflation data starting in 1960, or coronavirus data starting in 2019.

As pointed out in the post, it's pretty easy to switch between years. It's mostly a matter of it being unintuitive. Unfortunately this isn't at all unique to Safari. See this comparison of implementations:

https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...

From left to right: Chrome desktop, Chrome mobile, Safari desktop, Safari mobile, and Firefox desktop

I think at minimum they could've chosen 1980 or something as a default. 0% of their users were born today so not setting a default makes no sense

Since when would arbitrarily setting the default to the 80s and reducing the amount of needed clicks from 925 to 465 even be a suggestion?

We're actually expecting users to follow through on that?

No I wasn't suggesting it was the solution. Just a bare minimum. 0% of their users are born today. 100% are likely born with 30 years of 1980

Yes I agree, that ideally the users would find it more obvious how to use the date picker properly and not just tap the left and right arrow to navigate

However in the screenshot I posted, I don't think any of the solutions have made this functionality very obvious. Except maybe Firefox lol. But Chrome's implementation on mobile seems even worse than Safari's!

What would you propose as a solution?

Type in your own date as an immediate replacement. (Use separate dropdowns?)

400+ clicks isn't even a bare minimum. It should be considered broken and tossed out right away.

Not the parent but the answer is don't use the date picker at all for date of birth. The gov.uk site, which is generally held up as an example of best practice design and accessibility because they do over the shoulder testing on real devices with real users from different backgrounds advises to just use three text field with the number property.

https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date...

Indeed, here's their date component:

https://design-system.service.gov.uk/components/date-input/

(unlike the blog post, it uses actual Day Month Year labels rather than placeholders)

I have story about this one too. When I went to take a covid test ~1 year ago, they had an iPad for self registration near the reception. I filled it out, noticed this issue and sat down. An elderly lady came up and started going month-by-month back to her birthday year. I had to get up and help her.

It's crazy Apple hasn't fixed this.

The worst is when the date picker won’t let you select a date in the future, like a birthday, and so it’ll rubber-band your selection back to a valid date.

That’s all fine, except it does this validation on every change, rather than when the user has finished entering data. So if today is 27th Dec, and I wanted to enter 1 Jan 2000, I have to first change the year and only then is it save to change the day and month fields!

What’s worse is the year appears last/right hand side, so as we work from left to right the first thing the UI has you pick is the day, not the year. I simply cannot understand how these issues weren’t addressed before release.

I have this problem with thunderbird's calendar. It won't let you set the event start before the event end, even for a second while editing. So I have this common problem.

1. Have an "evening event" from 16:00-23:00

2. The start time changes (or most likely was previously a generous placeholder)

3. Update the start time to 19:00. Thunderbird automatically adjusts the end time to preserve the length. Now it is 02:00 the next day.

4. Adjust the date back, however after the first click it closes the datetime picker and throws an error.

5. Try again, select the future date to get past the date picker into the time picker, then select the correct time.

6. Open the datetime picker again, select the correct date and the same time.

This is a particularly egregious example because the datetime picker is combined and aborts half-way through after you select only a date.

Date pickers in general are terrible. Why on a form where I have type my email or shipping address can’t I also just type in a date ?

You can type the date in browser date pickers, including Safari's, even while the calendar is visible.

But the UI is not superfluous for many use cases. Often, you want to see the whole calendar for context -- eg, to see the associated day of week.

> You can type the date in browser date pickers, including Safari's, even while the calendar is visible.

Not on iOS (at least assuming you don’t have a hardware keyboard). The software keyboard does not appear and there’s no option to bring it up.

date pickers are great for selecting recent dates such as this month or next month. this works very well for hotels and stuff like that where you select multiple dates. i would rather date picker than type it in

It depends on the use case. For something like birthday, ID expiration date, etc., just being able to type in the correct values is the best UI. But for a use case like scheduling something in the near future (e.g. a flight, delivery, whatever), the calendar picker is superior because days of the week actually matter for this use case.

Exactly, a plain text field that does best effort parsing. If you want to be precise you can enter "2022-12-01", but if you are in the mood you can enter things like "tomorrow" or "first of the year", or "June 1 1999". UI could even show the exact parsed date below the field as a hint.

I know it's not the fashion now, but the jQuery UI date picker works really well, can be configured for various situations And let's you type the date instead.

I wrote code on the back-end to also parsing. So just type 11 for the 11th of this month, or 11/11 for 11 Nov this year. Or 11 Nov. Or next Tuesday. Or tomorrow of yesterday etc.

It also only treats the screen format as a suggestion. Like it wants dd/mm/yyyy, you can type in 1945/12/6 and it'll figure it out. (it uses the suggested format to resolve ambiguities)

Computers are good at this, and should do more if it. Don't get me started on Web sites that reject my credit card number because I type in hyphens or spaces. With specific messages like

"enter the number as 16 digits, without spaces". WTF????

I love when these fields are also length-limited so when you paste your 19-chars it cuts the last three.

The best is to have both. Let customers type in a date and show it in a calendar below so people can confirm it's the date they're interested in. Let them tap on the calendar to correct it if needed.

I once developed an unusually complex HTML5 Offline app, and found that Safari even had regressions on some basic standard behavior that I needed.

I know there's good faith work around WebKit, etc., by smart and genuine people. But it was easy to wonder (especially with the anger that comes from being existentially threatened) whether some element at Apple wanted to make Web apps work badly, to keep the proprietary App Store party going.

(I did pull it off successfully, but only with much heroics.)

It took me a few seconds to parse the calendar view, but my first guess about where to tap was correct. And I expected the month and year rollers to move separately, which the article says is counterintuitive. But I don't own any devices that run Safari, so maybe it's inconsistent with the usual expectations of the interface?

Look at the UI: The grey bar connects the month and year, making it seem visually as if they would move together.

It's a really terrible UI - why would the month and year both pop up at the same time? They should come up independently.

I disagree about them needing to be separate. Once you have that panel open (and knowing how to open it is the problem), you see the two high level selectors that you need. If you only need one, then the other is harmless and will not confuse you; you will just not touch it.

Of course it's better to have them moving separately, otherwise somebody would move 12*n times the month to move n times the year, before discovering that the year also moves, if they'll ever discover it. However a better solution would be to show only the month and only the year in two separate screens. No surprises, no chances of using the UI inefficiently.

And for 12 months, you can show all of them together on the screen. Same for the years, you can show more than one at the same time and scroll many of them together.

Absolutely they should _move_ separately, but they can both be visible at the same time.

I'm not suggesting that they are stuck together; that would be pointless.

I think you're talking about slightly different things.

The issue (which I agree with) is that the month and date "share" a continuous grey background which makes them seem connected.

They can be visible at the same time, but it would make sense to me to separate the backgrounds as to indicate that they can be scrolled separately before touching them.

Ok, I see. Yes I do agree that having some visual indication of independence of month from year would be better than none.

Although in this case since the only thing you can do is try to touch and move something, it only takes one "not sure what this does-touch" action to discover that they are independent; and then you know how to operate it. Not ideal, but low on the pain scale.

Popping them up at the same time is really good for "pipelining". I know that the year picker is next and I know where it is while I am entering the month.

If you hide it on a different screen I need to react to it when it appears.

Not to mention that you now need a "Next" button and a "Back" button in case I made a mistake (or just want to double-check what I inputted)

> Look at the UI: The grey bar connects the month and year, making it seem visually as if they would move together.

It does not, that interpretation does not make any sense.

Although I do agree that the old skeymorphic iteration of the control which made it clear those are wheels and the bar is an index was infinitely clearer: https://www.andyibanez.com/img/date_picker_pre_7.png

I guessed correctly as well due to the blue arrow next to the date indicating further interaction was possible. I have decades of computer use experience though. I'm not sure if it's intuitive for every demographic or what an appropriate interface would be for our elders.

Another anti-pattern this UI and most modern UI has is a dramatic reduction in the number of visual cues that identify interactivity. This is a system widget, and blue indicates interactivity... but that's almost it. The shape is often used for other purposes, such as for a breadcrumb, and actually the positioning makes it look more like a breadcrumb. Furthermore, it's going to be used from a website, and thus you can't rely on the fact that the rest of the site's colors will be consistent with this particular shade of blue on an icon indicating interactivity.

It's all rather minimalist - and if a user catches it, that's fine, but if they don't, there aren't any fallbacks or additional hints as to what to do. Additionally, the icon seems fairly small from the screenshot - though on an actual device that may not be an issue. It may be too small to function as a good UX element.

They're getting tons of customer service calls though. Objective data always beats subjective, and the objective data here is that a bunch of customers are confused and unable to use the website.

I have no doubt that 9/10s of people reading HN would be able to figure this out if not more. But what is the figure like out in the normal/non-IT world? I miss when Microsoft had their accessibility research lab that tested stuff like this scientifically and released tons of great papers. We need more of that, I'd love for Apple to invest in stuff like that.

> They're getting tons of customer service calls though. Objective data always beats subjective, and the objective data here is that a bunch of customers are confused and unable to use the website.

The problem is whether they're getting calls because the UI is objectively worse, or because there's an upstream selection issue: there are comments on the gist showing the UIs on other browsers are not fundamentally different, the biggest difference is that Firefox desktop makes it much clearer that the month/year is an active control, and the three desktop variants clearly allow textual input.

They also indicate that their population is:

> As such, most of our customers are in their 60s or older.

So sounds to me the issue is not that Safari is worse than the rest (although it's no better either), but elderly generally get (or get offered) iPads for pretty obvious reasons, and so there's a huge selection bias.

Now it seems the date picker, like the Safari one, is just meant to let you pick a recent date; for a faraway date like DOB, the weekday does not actually matter, so it is easier to ask the user to type. Just some quick thoughts after reading the article and comments.

The date picker only defaults to today's date if they don't specify a default value.

Tbh I think setting a default value might actually have been a better solution. It's not perfect, but hacking together your own alternative could lead to a number of issues for folks relying on screen readers and other input devices. The `type="date"` gives a lot of semantic meaning that `type="number"` lacks.

If you're gonna ditch it, I'd say at least use an existing external library that's been battle tested for accessibility.

What would a default birthdate be? That would span 80+ years. That's not going to work. Any time an input spans ~29k values, you better provide some logarithmic-time searching mechanism. So yes, Safari's date picker is f'ing dumb.

Which of these do you think did it better?

https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...

From left to right, that's Chrome desktop, Chrome mobile, Safari desktop, Safari mobile, and Firefox desktop

---

The post specified that the users are mostly senior. Regardless of what they go with clearly 0% of their users benefit from leaving it to default today unless they somehow figured out how to sell smartphones to fetuses

Also depending on the product and legal requirements the latest possible DOB might be 13, 18 or more years ago.

If a default value is set you’re going to have the problem of people skipping the field and submitting the default value instead. What is needed is a way of influencing the picker’s default view into year view with a default year visible, but without actually setting a default value. Only Apple can provide that level of control.

There is always a default value in a picker; if you don't specify one, the UI defaults to today's date.

You’re talking about slightly different things. You’re right that when the UI opens it’s always going to be on a default date, if you don’t set one it’ll be today.

But if you don’t set one then the value of the HTML element will be null before it’s selected. So if you add a required attribute then you can make sure that your users use the date picker (or leave in frustration after failing to do so) before submitting the form.

If you set a default value using the value attribute, then that becomes both the HTML default value and the UI default. IMO the spec is missing a way to just set the UI default, so that the field is default empty but interacting puts it at a sensible starting point.

There’s an MDN example here where the date starts empty and is required, if you try submitting the form you’ll see there’s no default for the HTML element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Hmmm, yeah I suppose that's true when using the `value` attribute,

EDIT: ignore the below. It was pointed out I misinterpreted defaultValue.

but there's actually also a `defaultValue` attribute which I believe behaves how you would like it to:

https://caniuse.com/mdn-api_htmlinputelement_defaultvalue

Ofc you can also use JS to make sure an input has been blurred or touched to pass validation on submit

That's not what `defaultValue` does. `defaultValue` is a JS (not HTML) attribute which simply allows you to retrieve the original value set in the HTML. So if you have this HTML:

    <input id="foo" value="bar">

Then `document.getElementById('foo').defaultValue` will always return `'bar'`, even if the user has edited the value in the field.

You're right, thanks for the correction.

Then yeah I suppose it'd have to be a javascript trick that sets the default value when the calendar is opened or, as GP suggested, something done at the standards or implementation level

If you think Safari is the new IE, you have definitely forgotten (or not experienced) how bad things were with IE6.

They didn’t just have a few bugs in their browser implementation or were slow to implement new features.

Basic, crucial CSS features were broken. Microsoft didn’t add any new features to the browser about a decade, basically holding the entire web back to the standards of circa year 2001 until it was finally safe to drop support for it almost a decade later.

And furthermore, Microsoft weren’t pushing users to upgrade to the latest version, so we had to support older versions of IE long after their replacements were released.

I understand wishing that Safari would be better, but luckily the Safari team is much more on the ball than the IE team ever was.

A few…?

It's not my experience as a web developer. It's 'a lot' at best. And not only in js, but also in css or literal anywhere you might interact to.

It always requires a few workaround when I finished the page in other browser. Firefox or Chrome, in the other end. If your page works on one of them, it will pretty much just work on the other.

Safari is probably 50% of my bug ticket, almost equals to every others sums together.

Write a page for safari really reminds me the age IE is still a thing.

Interesting. I've run into issues with the way Safari handles transparency values, but don't actually come across many other Safari specific issues these days. Safari has been pouring a lot of effort into improving their web compatibility recently and I feel like it's already making a difference

I'd be very curious to hear some common issues you have to deal with

I agree. The people who call Safari the new IE probably don't know what zoom: 1; does and how fundamentally broken so many basic things were in IE6.

You have a point, yet I feel the situation isn't as bright as you make it look.

I think Safari isn't broken in the ways IE was, because IE always had comptetitors running along it and pushing the enveloppe where Microsoft was pulling the brakes. Firefox and later Chrome were handicaped in adoption, yet had little to no limitations on the features they wanted to add.

In comparison no other browser can run with the same privileges as Safari on the phone, while the iPhone is a dominant platform. So there just isn't the same space to innovate in a profitable way. The only company who can afford pushing the envelope is Google, and at this point their only real competitor is Firefox, that they basically pay to keep alive. They also have little incentve to really push the web as it doesn't impact their bottom line (native app ads also go in their pockets afterall)

Safari IS new IE.

I have submitted 10s of webkit bugs and most of them will never get fixed.

New bugs randomly appear in every OS update.

5 year old cheap android device can handle complex webpages really well, but my 1500 eur brand new iPhone runs out of memory. iOS Safari is really buggy.

I work with online maps.

I think there's a hidden issue there: it's 2022, almost 2023, and we still don't have standardized auto-fill forms. Browser auto-fillers somewhat work, but because every website is implemented so differently, I always end up having to type my address number or birthdate again.

I can't see why there isn't an standard semantic web standard for this. We shoukd standardise how common fields should be named and their datatypes set once and for all. Example: set on a field for month AND a field for day. No more MM/DD vs DD/MM issues. One-click and it's unambiguously filled by the browser. Seriously, what's preventing this from happening?

I think my Safari 'autofill forms' feature fails 4-5 times in a year? Usually on a really shitty site or one that thinks it's clever. If you build your form according to standards with autofill hints you should have very little problems.

Sounds like a job for a LLM browser plugin :P

There is a standard for this. If you google HTML5 autocomplete attribute you’ll notice all the possible autocomplete attributes and those cover pretty much just about anything. To my knowledge, the major browsers implement nearly all of them.

What’s preventing this from happening? Nothing, clearly, devs just don’t implement it because they don’t know about it, and they don’t know about it because they’re busy learning about or implementing something else. How would you universally communicate to everybody that this is now a thing? How long will it take you to fix 90% of the forms out there that were set-and-forget five years ago?

Besides, for most it’s easier to use oauth with google or whatever and automatically get the name and birthdate from there (of course, often enough, they have the non completed form anyway…)

> use oauth with google or whatever and automatically get the name and birthdate from there

After recent story about github ban: https://news.ycombinator.com/item?id=33917962 anything that asks for more that email is a instant 'close tab and never return' for me. And even before, there is no way I am allowing any site to access may date of birth (despite it being fake one anyway)

And going back to "autocomplete" - it looks that browsers "know better" than developers: https://stackoverflow.com/questions/12374442/chrome-ignores-...

> anything that asks for more that email is a instant 'close tab and never return' for me.

OK? Unrelated to what I was talking about. I'm saying devs do it out of convenience. What you do with that is not their problem, really. Most people like Google auth.

> And going back to "autocomplete"

Again, totally irrelevant? I was not talking about autocomplete=off, but about the dozens of available autocomplete values, which is what leonidasv was asking about: A standard for the various autofill forms.

Funnily enough, you're nicely showcasing the problem yourself: You're a developer who didn't bother doing the research, and yet complains upthread about the lack of standards or whatever. I invite you to look at this page:

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

It is 2022: some JS frontend frameworks don't have `input` elements in DOM tree ( or at least it is nowhere near the place visible "inputs" are). I guess it is the result of standard elements not being customizable enough (and let's be real, there is never going be a point when available options are enough).

People remember their birthdate as a string of numbers.

So why use a date picker for this and not go with 3 number inputs which would be a lot easier to enter your birthdate in.

This is what they ended up doing.

However, they also mention that many of their users are on iPads. On iPad there is no numeric only keyboard so it's not the best experience. Not terrible, but it's annoying that iPhone has a numeric keyboard but on iPad it's just a full keyboard, even when you request numeric only. We ran into this same issue and ended up just creating our own keyboard to make input simpler.

Date pickers are one of the worst interfaces on the web. Everyone seemingly has a wildly different design and they're almost always hard to use and unintuitive. And forget about if you're picking a date _range_

I've been using daterangepicker [1] for ages, and it's one of the reasons I still just default to jQuery for web apps (the other being jQuery's custom event chain). Works well, very readable, easy to pass functions to disable individual dates which is important in reservations apps, ties in nicely with moment.js. More to the point, finding a decent calendar that didn't baffle users was such a pain for so long that I never want to have to do it again. And of course, with native browser components who knows what your user's going to see next year?

[1] https://daterangepicker.com

Call me an old curmudgeon, but the only place where date pickers make sense is in scheduling applications.

It is nice to see a calendar when picking a date for an Airbnb booking.

Picking a date for a future event is an entirely different use case than choosing a date in the past. The former is more of an exploratory activity; you are interested in things like the day of the week, proximity to holidays, availabilities, and all kinds of information, whereas a visual depiction of a calendar conveys valuable information, information that is entirely superfluous when picking a date in the past.

But registering dates is slow and cumbersome, more so if those dates are removed a few years ago, like DOBs and other similar kinds of dates.

Also, anything past the current month is a chore; manual input is usually faster and less error-prone.

The most straightforward solution I can think of is to split date inputs by context. Create an `<input type="dob">` that is tailored for picking a date of birth from 1900-today. "date" is too vague of a context to create an UX that works well in all the different contexts. It'll always be bad in some contexts, if it's trying to solve all the use cases.

This. In my form generation library (that I maintain and use for client apps) there are two types of datetime input areas available. They take the same arguments for ranges and single/double dates, with or without time, and at what frequency of time (e.g. hourly, 15 minutes, etc). One wraps a calendar library (daterangepicker) and attaches it to the form; the other generates a responsive text input with placeholders and danger labels. Their outputs are both returned as Moments which can be sanity checked, tested against other constraints and shipped back out as YYYY-MM-DD HH:MM:SS to the database.

This would be good, or maybe use type=date and inputmode=dob? As it affects the method of inputting what is ultimately still a date.

“It's not fancy, but it works. In fact, it works because it's not fancy.” is a lesson I wish was drilled into designers.

Here's how the UK government website's design team recommends doing it: https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date...

Was going to share that, their blog is a nice resource on the topic of accessibility

The UK Design System, who is known to have high standards on accessibility, does it like this:

- Pattern: https://design-system.service.gov.uk/patterns/dates/

- Research: https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date...

Just never use date pickers for birthday but for short term date picking like scheduling an appointment.

Date input can be DD, month in textform drop-down, YYYY and you won't have any problems anymore.

I don't understand why it is so hard for devs, PO,... to understand this :)

I’ve encountered this nightmare and couldn’t believe it was real. At least I didn’t have to scroll as far as some older people.

Solution: add a transparent native date picker transparently fitted to a drop-down/calendar icon on the right of the inputs. Requires JavaScript to sync value between native date picker and the xx/xx/xxxx inputs, and it requires some CSS to make the picker “invisible”, and tabIndex to -1. This gives users access to their localised date picker (which can be really important), and may or may not help accessibility. Not DRY, but it solves a bunch of different problems on different browsers (e.g. you can’t tell if a browser has a broken date picker).

This technique also fixes the issue where a Safari Mobile date picker defaults to todays date, for example when using > to move through existing dates that are empty (clicking Done unobviously picks today - often not what you want). Terrible UI for fields like birth date or employment end date. Although depends a bit on whether a blank date makes sense.

Oh, and be really careful of type=number on Safari - it silently fails. inputmode=xxx can help, but it has weird differences between devices last time I looked (versions, Android, iPad etcetera). My mum repeatedly failed to enter a dollar value into a type=number, because she was entering a thousand’s comma (the UI showed $ and , everywhere for numbers so it is a sensible mistake to make; although Safari will display the entered number in the input field the .value==0 —— arrrgh silent failures are hideous).

I hate Mobile Safari - buggy, impossible to get bugs fixed, relatively poor standards support e.g. still need -webkit- prefix for some standardised CSS from a decade ago. Oh, and you end up with people using obsolete phones stuck on old Mobile Safari versions. Android updates Chrome even if it doesn’t update the OS (although Android also has the problem, it is less of a problem).

Here's a simpler solution that's even safer for screen reader accessibility: use the platform

Just set a default date and it won't default to today.

When the date spans a wide possible period, like birth date, this approach doesn't solve the root problem.

Right, I agree. What do you think would be a better solution?

The date picker in the image is basically the exact same as Firefox and Chrome's implementation minus some stylistic differences.[0] Most native components also look a lot like this. So this isn't just a Safari issue but an issue across web UI in general

[0] See for yourself: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

> What do you think would be a better solution?

Better configurability which would let the author decide whether they want a calendar or a straight date input. Though I'm not sure iOS even supports a calendar-less date input anymore.

This is what the "date" control looked before iOS 14: https://i.stack.imgur.com/ms5tX.png

Rolling back the entire "flat" shit would probably be a good idea: before iOS 7, the control was functionally similar but had a lot more visual affordances: https://www.andyibanez.com/img/date_picker_pre_7.png

It was much clearer that the central shade is an index, and that the three fields are separate wheels. The iOS 7 picker makes it much subtler by simulating curvature, and the new sub-selector (year-month) does the same and makes the index kinda even worse by outlining it in an abstract shape: https://user-images.githubusercontent.com/6268177/209607212-...

You think that 1/3 of user support issues due to elderly accessibility problems is acceptable? That is the context the article gave us. And in my experience for every user support issue you get, there are 100 people that had the same problem but didn’t contact user support for whatever reason.

I am not suggesting my solution is perfect, but I am saying I have successfully used it (although I admit is was a few years ago now, and I first used it was when iOS and Android type=date support was unpredictably broken so type=date must not be exclusively be used). I think it was about iOS10 before the bugs in the UI to clear dates were fixed? Another situation for me was New Zealander’s confused by MM/DD/YYYY native formats when using browsers configured for US date localisation.

Until April 2021, Safari on Mac didn’t even support the date control, and Safari (on Mobile or Desktop) still doesn’t support the min or max value attributes. And time entry is a complete nightmare. I always try to make sure data entry controls work well for everybody, even console devices.

There are always corner cases that somewhat depend on your particular users, so compromises are necessary.

Background: I have programmed HTML entry controls (combo, date, time, number, etcetera) for actual man-years of my own life. That is because I started before jQuery existed, supporting IE5.5, and the available DHTML controls were mad broken for usability. I have had to understand the compromises between different solutions on different browsers, and try to find the most elegant solution, given that data entry on browsers is an extremely gnarly problem space.

No tbh I actually really like your solution compared to the alternatives that have been thrown around.

I'm just pointing out it's not easy to implement just to get the logic and styling to work right. And then on top of that, making sure it's screen reader and keyboard accessible adds another layer that is often simply ignored

The simpler solution I put forth resolves most people's problems, maintains the advantages of using native HTML controls the way they were meant to be used, and is easy to implement in... literally a few seconds.

Totally agree.

Custom entry fields have different compromises (oh defuckinently), and trying to be too tricky leads to corner-case usability problems and a heavy maintenance overhead in my experience. I judged it was worthwhile for our users’ needs at the time for me to spend very significant development time plus ongoing development time, but my choices would be totally inappropriate in many other situations.

> Here's a simpler solution that's even safer for screen reader accessibility: use the platform

That's exactly what's happening here though, Safari shows the platform's widget.

> Just set a default date and it won't default to today.

That's not really helpful either, DOBs have wide ranges of dates so the need to switch year, possibly decade (as this is for the elderly) will always come up).

I absolutely cannot stand those scrolling selectors. They're a UX nightmare in every possible way - literally every one of them would be better replaced by either a normal list, or (when they're numbers) a number input field.

iOS used to use those exclusively to pick times for alarms and such, and I could not for the life of me understand why I'm spending all this time spinning wheels up and down trying to get it right when just typing in "1030" is done in 4 taps

If you’re not aware the iOS time spinner has a hidden number input that comes up it you tap the wheels. So one extra tap then 1030 will get you what you want. Impossible to find without being told it’s there though. And as far as I can tell there’s no date equivalent.

Android too, though the tap area is much smaller than it should be for what I am sure are completely defensible accessibility reasons.

Just have three separate drop downs for year, month, and day. Problem solved. Unambiguous. Bug free. Works without any extra JS.

Then people will pick June 31

Year drop-downs are annoying for things like DOB because there are 100 choices to scroll through. Reminds me of my Humana insurance app where some questions had drop-downs of literally 1,000 values, so I'd swipe and swipe for several minutes, but if I swiped outside the box by a little bit, it would collapse and I'd have to start over. Eventually found that I could select a part-way value and then start swiping again, and if it collapsed I would at least go back to the part-way value.

So, typing in Y/M/D is better in most cases for DOB than drop downs, unless maybe it's dropdowns for [YYY][Y], then [MM] and [DD]? Or how about start with "How old are you" and then get me most of the way there on the picker? :-)

While I don't claim that Org mode's `org-read-date` is ideal, I have yet to see a better date input UI.

Also, ISO-8601 not being universally adopted is a shame.

If anybody else is now thinking about alternative possible designs and wants to explore the way different design systems do it:

https://component.gallery/components/datepicker/

Hell, I’m half as old as those customers and the date-picker is still annoying AF for birthdays or really anything that’s not this month. It’s just a shit design, likely created by some PM who couldn’t think beyond their weekly work meetings.

One interesting alternative (that I can’t remember actually encountering, but just occurred to me when reading this) would be to have an Age numeric field before the calendar, entry in which would jump the calendar to the corresponding birth year.

I built an example that uses separate select tags for year, month, day, and time.

The benefits of doing this are:

- Standard elements that work everywhere

- Easy to refresh the available options after a date change

- Mimics the "rolodex" behaviour to quickly find any date/time

The libs I used are arbitrary, won't be hard to rewrite using only built-in Javascript, or any library / framework

https://www.mozey.co/demo/ts/examples/datepicker/

It's not just the date picker in Safari. iOS in general... I don't get it why I need to uninstall and reinstall an app from the app store when I want to clean the app's data like I can easily do on Android. Why is there no way to clean caches? Instead a big chunck of the storage is filled with "other system files". And the keyboard is so error prone as well, I always do spelling mistakes or need hours to type short texts. At least it's just my work phone...

Even worse: I saw several websites, where this exact UI was carefully replicated with HTML custom control. NB: I am 47.

The solution works until you expand beyond the US to people with sane date and unit convention :P

DD/MM/YYYY is the way

purely safari's fault, makes sense otherwise to have this on the browser side.

Next challenge: A sensible input for a date range with optional time of day. Have not seen a good one yet I think, especially when you try to correct your made input.

Sensible is the ISO 8601 standard with the RFC 3339. It's already been adopted by tech and governments and keeps all time big endian (bonus: it's alphabetical too). But LOL AmErIcaNs month first, right?

this is about ui, not data storage

Yeah, and it's easier to parse big endian all the way down. It doesn't tend to cause the same ambiguities that make folks have to double take to understand the data.

A different pet peeve of mine on iOS is the USSD menu which is center-aligned, and i find that very ugly. Maybe the usage of this menu isn't universal but for someone from a developing country, we use that like a million times a day. Mostly we are choosing a menu item to continue with a dialogue and the numbers are not aligned.

the rolling wheel thing is terrible for another reason. your finger obscures the value when you roll back (up). it’s horrid

And lacks the semantic information that's used by screen readers. If you're gonna ditch the native elements you should probably use an external library that has meticulously worked through all of these issues

Agreed. I'm an iOS user primarily and have been since almost iOS 1. Some android intermittently.

I have no trouble figuring out how to pick by year because the rest of iOS follows a standard UX.

It seems more important to me to support the native accessibility of the phone than use an external UI vendor.

I am a huge advocate of family members and elders to purchase devices they are comfortable operating. This is why my grandparents primarily use their desktop computer for any important things, and their iPhones for messaging/video chat.

Every year I get progressively angrier as I have to scroll through a GODDAMN SPINBOX on my phone to select my birth year.

Spinbox is great if you need to increment like 5 items up or down. Not 30+ and CERTAINLY not starting at goddamn 1900 and making me scroll down nearly 100 entries.

People who do this need to go to jail. Forever.

Anybody going to address the elephant in the room that this startup is probably fraudulent and peddling pseudo science?

https://geneticure.com/

Does anything they say read like it’s been backed up by peer review studies?

I'd have the same concerns. Fortunately our research is in several peer-reviewed journals, like the Lancet and the Journal of Clinical Medicine. We list our research on our homepage: https://geneticure.com/#article

So let’s say I use your service, then what? Do I hypothetically take the results to my doctor and will they prescribe drugs based on the recommendation?

This is semi relevant to me, I do have high blood pressure at 49 that’s well control with what amounts to a standard diuretic (Hydrochlorothiazide).

Yep, that's exactly correct. We lay out the process at https://geneticure.com#howitworks, but you've already got the idea. I'm happy to answer any questions — if you email support@geneticure.com I'm one of two people who looks at support/info requests.

I’m going to now admit that I don’t know enough to know how valid the testing is.

But, I can say that on an individual level it is easy enough to test whether a blood pressure regimen is effective.

Blood pressure is easy to test at home and the effect of a blood pressure regimen can be observed almost immediately - within 24-48 hours. So if the doctor recommends that I change drugs and measure my blood pressure daily under the same conditions, we can judge its efficacy.

In other words, I would be more comfortable with experimenting with different approved high blood pressure medicines than something like cancer medicines based on a startups recommendations.

You're absolutely right. However, that trial-and-error can be really difficult for people who have less ability to maintain immediate communication with their doctor, retrieve a new prescription, etc. For someone like me in their 30s it would be a minor-ish annoyance, but for someone who is elderly, or who is having some sort of medical emergency, such an inefficiency goes from being an annoyance to being a pretty critical issue.

I’m shocked that there’s such a myopic view of “date” as a type in design that we don’t really see concepts such as “expected date range.” Am I expecting an input that’s years ago? Recent? The future? These would all be very different widgets if designed well.

As a long time Apple user, the solution advertised in this is actively worse. Typing in a date manually is absolutely slower than quickly flicking to the year and the month and then touching the date.

Please don't force users of mobile devices to type in a date.

I use a very simple drop down prefixed with ISO week numbers here:

https://stay100.app

It looks simple and basic, but <select> works very well on all devices.

Thanks no thanks, what an abomination.

Color picker also. The crayon box is crap.

Honestly, this aspect of Safari's UI (the default form input widgets for complex values) is severely under-worked and in desperate need of an overhaul.

Android date time picker is also fancy but icky imho. I don't know how it performs though

Honestly , 3 select boxes are so easy to understand even if they are somewhat clutter

If I remember correctly WebKit replaced the 3-wheel date picker with this recently because people thought that was too skeuomorphic. Guess they can’t win?

It's also exactly how Firefox and Chrome's date pickers look. So they were probably to up their web compatibility game to look like everyone else and give users a more consistent UI

Some of these new (unified) UI elements are just awful.

My pet grievance is the range input, which is now filled by an accent color from the left (start) up to the selected value. Meaning, if you provide your users a range from -200 to +200 to select a value from, and a user selects a value of 2, this represents a selection of 202 units, which is apparently the real meaning of the number 2. (As is, Safari is the only major browser not participating in this nonsense.)

This is one of those basic UI things that are missing/bad in native HTML controls, and why we end up having to implement this stuff in JS.

and inevitably those JS implementations almost never take into account screen readers. I think we should use the platform as much as possible for this reason

90% of the annoyance could've been dealt with if they had just chosen a default date value of, say, Jan 1960 or so.

...which means I just need to click the ">" a couple hundred times.

Well I mean you don't. And you know that. And 95% of internet users know that. It's just an issue with elderly folks not being familiar with this UI

Maybe the real solution is a simple explanation for how to use a date picker component. It'd help those users not just on this site but on many other sites in the future.

Tbh I don't really know what improvements could be made to the picker itself. It looks pretty consistent with the implementation of most other browsers and OSes and even most native components I've seen

I'd love to hear actual thoughts on improvements though

It would be nice if Apple had like a DateKit or something that standardized and nudged developers to integrate natural language date entry across the OS.

It needs to stop being a blockbuster feature that lets companies/products like Fantastical that bait and switched their paid users limit their competition. If Apple can spend the amount of time on things like LiveText and their creepy NeuralHash program, they can take 5 seconds to implement easy date entry.

Safari's Rolodex date picker sucks out loud. I'm so glad they are getting called out on this.

The only correct date widget is a second counter from epoch with a + and a - button.

GitHub Gists are not a blog.

> I chalked up the "New IE" stuff to annoying little CSS issues

Here, too, Safari is the cause of 2/3rds of the lines of exceptional UI code now that Edge switched to a compatible render engine. Or blocks features altogether. All major browsers settled on doing things a certain way and then you remember that you always need to check Safari and of course they want it another way, so you get to re-do the work and duplicate your code with a comment "//because safari wants x to be done this way". I had less trouble with MSIE6 back in the day, though I can't rule out that I did less fancy things back then.

These things are not like "oops we render it differently by chance", it's conscious choices like not supporting SVG or being able to read file names in JavaScript (can't have javascript-based upload progress bars or local file encryption if you want to keep the filename; need to encrypt on the server and have the server report progress back via another channel).

> now that Edge switched to a compatible render engine

What is the definition of “compatible” here?

The point of “one specification, multiple implementations” is to explicitly leave the door open for slightly deviant implementations.

My definition of compatible is basically what I described in the comment: "[not being] the cause of 2/3rds of the lines of exceptional UI code".

There's the occasional situation where Chromium doesn't support something or Firefox doesn't support something, but it feels like Safari has double the rate of both combined.

The computing industry has a pretty poor track record of multiple-implementations ever agreeing or being a net positive for the user. Instead it always seems to devolve into pile-of-hacks for platform X and pile-of-hacks for platform Y, regardless of what the specification says.

Can any browser that is not a reskin of Chrome with feature and bug-for-bug parity actually satisfy web developers at this point?

If Firefox had the marketshare of Safari and was mandatory to support because they were a major platform’s browser devs would be cursing their name too but with a different set of things that aren’t exactly like Chrome.

It really does feel like devs are literally developing against Chrome with not even so much a thought at cross-browser compat or a glance at caniuse and then taking their finished site and then working backwards from there on other browsers cursing the compatibility issues when they could have avoided it entirely had they started with a cross-platform subset of browser features. Just the same as how cross-platform native development works.

Hell someone did all the hard work for you https://github.com/amilajack/eslint-plugin-compat

Then multiply by all the npm packages blindly imported that were developed with the same methodology and I see where the rage comes from.

I develop with Firefox on the desktop, and for the vast majority of cases if you develop for Firefox on the desktop, Chrome just works perfectly fine, and most of the time the mobile browsers work as well.

Safari (mobile), however, will be broken. Firefox on Android often breaks for more complicated stuff, but works better in my experience.

> If Firefox had the marketshare of Safari and was mandatory to support

Uh, it kind of is? At least, I use Firefox exclusively and thus also support it when developing things.

The browser I have trouble with sometimes is a webview skin on mobile (whose engine is blink or whatever it's called nowadays), there some sites block the http user agent string for some reason or it's missing some advanced this or that and I have to switch to mobile firefox which is a lot slower.

> Can any browser that is not a reskin of Chrome with feature and bug-for-bug parity actually satisfy web developers at this point?

Uh, yes? Firefox? I don't understand your question.

> now that Edge switched to a compatible render engine

Not “compatible”. The same render engine.

Edge is essentially just Chrome with a slap of Microsoft paint.

That’s nice for uniformity, but having all browsers use the same engine is not good for the health of the open web. We do not want Google as a single point of failure any more than Microsoft.

Hah, tell that to Edgium. There are still incompatible sites, same as with Google Chrome® and Chromium. Their own Google Meet will not work properly in Chromium whereas it does in Google Chrome and Firefox. I don't use Edge myself since I'm on Linux (though, surprising fact of the day: there is an Edge release for Linux!) but my girlfriend has stories (which I apparently failed to remember or I'd give examples now; they might also be company intranet sites though). Might have something to do with trying to be more IE-compatible.

The pick date widget is (at least for me) a solved problem: Use the jquery ui datepicker.

The fact that a lot of people prefer to avoid using jquery (for no particualr reason) and all its widgets and instead try to re-invent the wheel (in a much inferior way) blows my mind.

Do you need to know the exact birth date or just the birth year?

Safari's date picker really isn't that hard to use.

You can't really blame Safari for the fact you shipped a site that requires users to tap a button hundreds of times.

That tells me you didn't once use your site the way many of your users do. That's completely on you.

Or that they shipped and tested this page prior to the release of iOS 16 as that’s when the UX of the iOS date picker changed to this abomination

That's just not true.

Talking about dates and Safari, be aware of this in JavaScript.

new Date('12-27-2022'); works in Chrome but returns an invalid date in Safari & FireFox.

new Date('12/27/2022'); works for all browsers.

The first format makes no fucking sense to start with, the US is the main country which uses mid-endian dates and it doesn't use "-" as a separator.

But beyond that, don't use `new Date(string)`: the only spec-defined format is a restricted ISO 8601[0], though the horror show that is RFC 2822 datetimes is conventionally supported by everybody because it's the standard stringification (Date#toString).

Everything else is implementation-defined, and likely heuristic.

[0] https://tc39.es/ecma262/#sec-date-time-string-format

Now you understand why people use JS-based UI elements.

What do date pickers in other browsers look like?

The Android one always makes me chuckle when some obscure site decided to use it. It's so unexpected to get a big pop-up in an entirely different UI style as the rest of the website suddenly, and when I realize what monster I now have to fight, idk it's humorous to me. It also differs between versions but hasn't gotten better.

I have gripes with Safari, but date pickers isn't one of the things only Safari struggles with.

An image search for 'android date picker' brings up at least three different designs: https://i.stack.imgur.com/3DW4n.png https://i.stack.imgur.com/LLRmB.png https://i.stack.imgur.com/kJqln.png

thanks for the screenshots

It seems like the first screenshot is `type="time"` and the second and third are `type="date"`. But I don't know if those are native components or the browsers defaults. Would be useful information

And I think all three of those are out of date, the Android 13 one is totally different as well.

Time to update the image search results! Sharing is caring ;)

I wish, I can get the screenshot but there's no easy way to get that on the internet

Try https://snipboard.io (iirc I found them via HN, https://news.ycombinator.com/item?id=4887660, used to be snag.gy which imo was a much nicer domain but oh well), I use that to paste-and-forget images that I don't care much about but want to be longer-lived than on dro.pm

Here you go!

https://snipboard.io/8fL9Kl.jpg

That 2018 and the top left gives you a selection for all of the different years

I just tested it in Google Chrome on the Android 10 device I have for testing and got yet another design https://i.imgur.com/4w8IvO8.png

Do you not have other browsers installed? You can open it up yourself by opening this URL

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

But yeah that's a good point. I'm on Firefox on Mac and it looks pretty much exactly the same. I don't really get why other browsers wouldn't be causing the same issues

From the screenshots it seems like they're talking about users on a mobile device. iPhones only allow you to use WebKit, but I'd be curious to see what Android's date picker looks like

I feel like they could've just saved themselves the headache by setting the default value to 1950 or something

Chrome for Android’s picker is worse in every way I can think of:

Video: https://imgur.com/a/W196T5f

iOS keeps the input on screen, so you can see the value in context. Android covers it up, and shows the value in a different format in the header.

iOS shows the Month+Year inside the calendar, with a blue arrow beside it to indicate interactivity. It’s not a strong affordance, but it’s something.

On Android, nothing gives any such affordance.

Blindly tapping the month+year in the calendar does nothing.

Blindly tapping the day or month on the header does nothing.

The year looks similar to the day and month, only smaller, and slightly darker grey. But if you tap it, you can scroll through the years.

There’s no way to scroll through months – the only option is to tap through them one at a time.

Oh jeez, yeah that's bad. What Android version and browser are you on?

This is vanilla android 13 with chrome 108. (IE – the newest ones)

Firefox and Samsung Browser are basically the same thing with different colour schemes.

Samsung managed to make the year seem even less tappable: https://imgur.com/a/2q4CiXk

Wow good to know, thanks so much. What a sorry state date pickers are in on mobile :(

Also wild how this post is singling out Safari when Android seems to somehow be even worse

> Also wild how this post is singling out Safari when Android seems to somehow be even worse

My guess is that it is selection bias. Older people are probably more like to use iOS devices, since they are marketed as being simple to use and maintain. So, they don't hear too many complaints about Chrome on Android, even though it's worse.

I like this as an alternative

https://github.com/mikepage/headlessui-datepicker

How do I change years? I couldn’t figure out how to quickly enter my birthdate with this.

Has the same problem as OP - no obvious way to select a birth date without many interactions.

how this can be a good alternative? I doesn’t let you insert the date manually on mobile and there is no way to pick a different yea

Is this a troll? At least the native picker allows you to skip between years. Seniors are finding a hard time figuring out how to use it, but at least it's possible

This implementation literally forces you to use the arrows...

As constructively as possible: This is awful.

This is why we can't have nice things.

tl;dr elderly can’t find the year picker in the iOS version of the date picker pop-up.

I feel like the data is flawed. This is (supposedly) 1/3 of tech issues raised by customer support — how many of which are total?

Edit: I have removed this comment due to post-specific moderation downweighing.