since the author brought up the native <dialog>, developers chose custom implementations of dialogs because they want better accessibility, better focus management, better mobile and touch screen reader support, and more flexibility. adobe's implementation is far more robust and flexible compared to the native dialog, and it's hard to justify "use the platform" when it results in a strictly worse end result.
Yeah, that was kind of ignored in the article and it's definitely an issue for some platform features. Date pickers are another one where it's easy to outgrow the native implementation.
I was excited about the native date picker and tried to use it once, only to discover that you couldn't (can't still, I assume) disable dates other than by setting min and max. Every native browser widget I've tried to use doesn't implement the features my clients expect, so I don't use them. People want a better web platform and the only way to get it is JavaScript.
That lets you bring up the picker, let the user pick any date, and then show an error message if they picked an unavailable one. It doesn’t let you show dates as unavailable in the picker or prevent the user from picking them.
slopinthebag · · focus · HN ↗
uhoh-itsmaciek · · focus · HN ↗
DangitBobby · · focus · HN ↗
JimDabell · · focus · HN ↗
“We need a date picker to schedule a visit.”
“Okay, use `<input type=date>`”
“It needs to be a date in the future.”
“No problem, add a `min="2026-10-05"` attribute.”
“And we’re only available on weekdays.”
“Okay, throw the native date picker away completely and build one yourself from scratch.”
Did nobody involved ever bother to ask what the requirements were for a date picker? Excluding dates is one of the most common requirements there is!
pwdisswordfishq · · focus · HN ↗
JimDabell · · focus · HN ↗