JS does not 'just work'. This is why a lot of these custom components have bad touch interaction and no accessibility.
Take the datepicker; the native mobile version works great, why annoy users with a custom component?
Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on.
My users always appreciated these buttons and modes because they were working in accounting and picking dates from that stupid standard picker was an ordeal. “ / / “ pattern is also annoying because you have to be precise with your cursor.
That said, ios picker is great, and it’s unnecessary to replace it. But (1) it’s not the only useful mode of operation, (2) it wasn’t always great on all platforms, and (3) html attributes usually suck at describing what patterns and use cases you want and compatibility among browsers is a minefield. I mean not only dates here, also numbers and ~numeric fields.
That's totally on point, but I think the core issue is less about "why the native date picker isn't always appropriate" and more "why do we keep half-assing non-native alternatives?"
The way I see it, so much of the web is a clunky mess precisely because software development today pretends to be engineering while simultaneously being about the bottom-line and little else. No doubt, a great date picker could be developed in JavaScript that would serve everyone's needs, be totally accessible, and not a bowl if <div> soup. So why don't we do it? Why are what should be basic HTML forms on corporate websites difficult to navigate or in some cases fundamentally broken, requiring workarounds? Nobody is interested because solving real problems doesn't carry any of the prestige of building another framework. Who wants to build a date picker that is standards compliant when you could write another web framework, bro? Even if a developer is not trying to build the next React, they're probably spending more time on their toolchain than actually coding. It's gotten so bad that seemingly every company I've joined in the last 6 years needs a bunch of people dedicated to maintaining toolchain and CI crap for the rest of the team.
I love programming, but the web needs to get its head out of its own ass. We're acting like our jobs are more important than the value the software delivers, and more effort is being put into making sites impractical for machines to parse (because muh intellectual properteh!) than in making web components that aren't riddled with bugs.
There’s a little more harshness than needed in your comment, but I generally agree with it. Having brought this up before, I’ve usually seen either no or strange reactions to it. It feels like web dev consists of people who only have done their job for an unknown faceless client sitting behind layers of teams and toolchains. Driving to a specific person, listening to their brutal feedback on your system and being asked to maybe fix it right now would be a sobering experience to some of them.
You're absolutely right on the 'why' part, but sadly a lot of custom implementations are annoying in terms of UX and accessibility. My only point here is that building proper custom components is far from easy, it takes a lot of time and effort.
* Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example).
* No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to fix every client configuration - not very likely even in small companies.
* No way to have the datetime dialog open by default.
* Poorish but getting better keyboard support (the pagedown-up keys finally work in most browsers, but once you've opened the dialog you can't enter a new date with the keyboard).
* Timezones must be handled separately, which is just poor design.
> ...place the user in American-style MM/DD...
> No ability to force date style by design.
There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc.
The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve.
> Lets you enter nonexistent dates like 31/2
This may be an issue in specific browsers/versions/os. But enabling the "validation" by setting required and/or some other attributes, gives an error for these dates AFAICS. But, in any and all cases: server-side validation is needed anyway. You just cannot trust a value sent by a user, whether that's "validated" with sixty npm-packages and their dependencies, or by the browser.
>The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird;
Legacy Edge used to look at keyboard locale and ignore the actual region settings. I have no idea why chromium uses MM/DD on my machine when Firefox does DD/MM. Back when $COMPANY used HTML date widgets we got a small but constant stream of complaints which we tried to triangulate (that's how I know about the Legacy Edge behaviour), but we never understood most cases.
Autodetection has been broken on a tail edge of cases for a long long time, and nobody in browser space seems to have any interest in fixing this - or worse, allowing the server to set the correct date style. The only practical fix is JS datetime widgets.
>or at least not a problem a web-dev should solve.
I think 'a not-insignificant amount of people constantly enters the wrong dates and eventually bothers support and writes bad reviews, plz fix this' is a good business cases and is something web-dev should try to handle.
>> Lets you enter nonexistent dates like 31/2
>server-side validation is needed anyway.
True, but it's a better user experience to disallow this also on client. If we only let the server do validation, why do we even bother with the SPA and the sixty-thousand one-line npm packages?
I normally use en_US but I want dates formatted as DD-MM-YYYY (or using dots, slashes etc ) and I want a 24-hour clock.
LC_TIME does not work very well with most apps.
And there is a big difference between just throwing an error if a date-time cannot be parsed because of a nonextent date, and communicating it to the user in a nice way, especially without using JS.
But the webdev has to solve this problem. Users with wrong locales and not aware of that are not very uncommon. I would also love the US to fix their stupid date format and even fully adopt the metric standard but sometimes you have to compromise and write code instead.
WRT dates, there's no "metric" standard. Not really. E.g. Belgium commonly uses DD/MM/YYYY whereas the Netherlands uses DD-MM-YYYY. Both use "metric standard" for lengths, weights etc. Same with currencies: "13,37 €" vs "€ 13,37" vs
"€13,37", all depending on where in Belgium you are from, vs Dutch in the Netherlands. It's an utter mess.
Which is another reason to let browsers - the user agents - deal with this. There's absolutely no way a lonely JS dev, or even a community around something like MUI to get all this right. And they don't. There's always something broken for me with these custom elements. If it's not some US-centric web-app enforcing their MM/DD/YYYY format, then it's some "ignorant" dev being unaware that in Europe in many countries decimal separators are a comma, or that in Thailand the current year is 2566 and that this is not "too far in the future".
> the native mobile version [of datepicker] works great
Strong disagree. It does work for simple forms, but definitely has a variety of quirks on different browsers/devices. Blank dates are especially quirky. Try “tabbing” through a date on iPhone or iPad and have some poor UI. datepicker really doesn’t work well for some less common situations (cut n paste, copy, from/to date, restricted date min/max past/future, year pick, month pick, etcetera).
Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on.
My users always appreciated these buttons and modes because they were working in accounting and picking dates from that stupid standard picker was an ordeal. “ / / “ pattern is also annoying because you have to be precise with your cursor.
That said, ios picker is great, and it’s unnecessary to replace it. But (1) it’s not the only useful mode of operation, (2) it wasn’t always great on all platforms, and (3) html attributes usually suck at describing what patterns and use cases you want and compatibility among browsers is a minefield. I mean not only dates here, also numbers and ~numeric fields.