I've dynamically updated <datalist> on a site, only to find out that browsers will only show options that strictly begin with whatever you've typed into the <input>. When you want to do Google Search-esque suggestions, that's a problem. I don't know how to override that to force it to show all options.
An awful lot of "AJAX" Javascript use could just be frames and iframes, if they were somewhat better.
Form validation should be built-in (with optional light JS for defining non-built-in validators). The browser should supply a lot more input types, including some kind of payment integration. It's absurd those things have to be built over and over and delivered by the website.
I could go on. It's a damn shame.
Have you used pattern attributes?
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
It's heavy-weight, fragile, lots of implementations are framework-specific, and most of them are horribly buggy, but it's nonetheless a must-have feature in many cases. It'd be a great candidate for better support in the browser, generally, if we're going to insist on using it as an application platform.
I don't remember having that last time I had to implement serious drag and drop, about 4 years ago.
This just made me laugh because it is so true. I thought it was just my stupid luck that I keep working with companies obsessed with drag and drop. But you are right. I have seen companies blow hundreds of thousands of dollars implementing drag and drop on a trivial feature. The same company will then complain about spending a few thousand dollars implementing a security feature or implementing training programs to teach employees about the importance of securely handling PII.
Edit: PII = Personal Identifiable Information (social security numbers, credit cards, birthdates, etc).
You are both right. Drag and drops are incredibly intuitive for users. It feels natural to most people and is easy for many of them to use.
But the parent comment is also right because drag and drops are not very USABLE. Meaning that if someone is using a screen reader or an unusual device (phone, kiosk, kindle, etc) the drag and drop functionality may not work well for them or might not work at all. It might be INTUITIVE on what the user is supposed to do, but it isn't USABLE. We have all encountered non-usable interfaces that we simply can not interact with for various reasons. This also becomes a concern for accessibility. A screen reader may not be able to read it to someone who is blind. An older device might not be able to display or operate the drag-able functionality. A user that relies on something like "Voice Control" may not be able to use your drag-and-drop system.
Ideally you would do both. You could show an interface that has up and down arrows for each item to move items manually. But also make those elements drag-able if users choose that option. But this takes more and more development time. That is the constant battle between software engineers and decision makers. Anything is possible with enough development time, but decision makers are quick to move developers along when the item is "good enough", which generally means the feature works on the decision-maker's devices.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
The problem is that some HTML form controls cannot be styled with CSS to render consistently across browsers. So, many sites fall back on JavaScript to render the control. Here is an example from 2016 on styling HTML checkboxes and radio buttons to make them larger (which, as far I can tell, is still a problem): https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-...
And iOS 14.5 (well, 14.5.1) is also current: https://support.apple.com/en-ca/HT211808#1451
But we'll have to wait a few weeks to months before all Safari users upgrade and see the latest improvements.
Does that mean only fully up-to-date macOS gets it, or do Safari versions move independent of the OS?
In rare cases, Safari features require a capability only available on the latest macOS.
On Firefox, the date picker is good and I can easily navigate to a year from muscle memory. The same wouldn't work on mobile, so they have different UI and controls. I don't want to use iOS style date pickers on my Android, or the other way around just for consistency.
Many custom date pickers are sluggish and has bad UX, and adds a lot of extra validation complexity with pseudo elements.
IMO we would be better off moving most of these things out of the browsers and into some kind of web component standard.
This way, modules can declare that they need certain functionality and then the end user provides it: instead of npm-style infinitely-deep dependency trees.
https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1