Great satire but let's create that same for combobox with server side filtering. Now you have problem because it's not possible with native HTML elements. Many re-implementations are result of missing native elements.
I didn't read any satire in the article at all, it just laid out all the built-in behaviors that a proper button has, and how much work it is to reimplement all of them. Something declarative and CSS-like would have been ideal for customizing elements, but instead we got the half-assed Custom Elements API and the completely different DX atrocity that is Web Components.
I can't really fault Custom Elements too much though, it's an imperfect API for an imperfect DOM and it's better than waiting forever for perfection. But I don't extend the same generosity to the Web Components spec.
But there is. You'll be so happy to learn about datalist today,
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_d...
It took forever but safari mobile got it right.
Extra fun to be had if you attempt to dynamically update the list.
Conclusion: utter garbage, stay away from it.
I just typed this by hand (lol) in 3-4 minutes:
https://jsfiddle.net/tjc4mpxe/
This is what we are waiting for? This is what is taking so long for browsers to support?
We've had things like https://doc.qt.io/qt-6/qtwidgets-module.html since the late last millenium. Back in the day, there was Delphi, now there is Lazarus, with even nicer Data-Bound widgets. Look at some tutorial for those, that's like magic, and also from before 2000!
Does anyone know why there have been 3 lost decades in native HTML widgets? Any ideas how to fix this?
Somewhat tangentially, the official response to a request for WebAuthn without JavaScript[1] was that the big websites don’t care and thus neither do the browsers.
For example, they've recently introduced the Interest Invoker API for tooltips on hover. Tooltips are ubiquitous, but they still haven't settled on what the trigger is for non-mouse users. Long press for touch is far less discoverable than mouse hover, for example.
Maybe it's a good thing they didn't rush this design three decades ago, when virtually all users were on desktop.
Maybe VR glasses will be big soon. Do we trigger on 'blink'? 'look harder'? 'eyeball wiggle'?
Maybe voice interfaces? Trigger on 'say it louder'? 'stuttering'? 'hesitant'?
Maybe guestures, facial expressions, thought patterns? 'think hard about that button to trigger tooltip'? 'furl your eyebrows'?
As I've said, decades have passed with no progress. If progress in other fields is a reason for waiting, it'll be stagnant forever and eventually just dead.
Google was very, very, very late to the project and of course immediately trampled all over it like they did with all the web standards.
Apple isn't holding back progress on that. They are all in on it, though they do tend to be more cautious than the "break fast and lose things" Google.
Missing part is dynamically updating the datalist in an efficient way
The one exception is Safari which has been slowly getting more and more special over time when it comes to web standards but is still relevent. If Safari found their way to supporting it then you shouldn't need to completely re-implement a button or combobox and instead just improve the native versions.
There are UI components that are not available in native browser controls (infuriatingly: some are only available in some browsers on some platforms), but even then you're better off writing a shim to replicate normal browser behaviour than ruining the experience for everyone because Firefox on Android doesn't have a colour picker.