Comment by mireq2
5 days ago
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.
5 days ago
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.
Anything doing server-side work is going to have to be at least somewhat custom. The main problem is there isn't a standard "combobox" at all to speak of: we're still mostly stuck with the same carved-in-stone widget set from Mosaic, whereas native toolkits were more inventive even in the late 80s. Where's Athena's 2d panner widget, for example?
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.
>The main problem is there isn't a standard "combobox" at all to speak of
But there is. You'll be so happy to learn about datalist today,
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_d...
It use to work but chrome on android shows the datalist items as a horizontal scrollable row above the keyboard (useless) and ignores input (even more useless) on windows it shows the datalist as a scrollable popup (confusing?) and ignores input (useless) while firefox on android completely ignores datalist and on windows you have to click the input twice to have the initial list show up.
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?
I imagine the commenter was referring to the article title wrt satire.
Fair enough, I'd call it "homage" perhaps.
Right, and the article kind of proves your point even a plain button needs formAssociated + ElementInternals to feel native. A combobox with server-side filtering is a whole other galaxy.
Correct me if I’m wrong, but my understanding is Google would love to make more web standards native (including selectors which have improved on chrome but are basically broken on safari) but Apple holds back progress in a (borderline?) anticompetitive way
I'm not sure if it's Google's fault alone. My impression is, all browsers are holding back on everything HTML-native and JavaScript-free. There have been literal decades of no progress, and only tiny steps forward as of late.
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?
> My impression is, all browsers are holding back on everything HTML-native and JavaScript-free.
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.
[1] https://github.com/w3c/webauthn/issues/1255
1 reply →
I guess the main issue is that HTML was supposed to be a language to describe documents. We abuse it to design interactive applications. I would rather like to not have one technology to support to different use cases. It’s a shame we are riding that abomination for developing apps.
1 reply →
My guess is that it takes time to research what universal behavior users expect from a component based on examples in existing software. It's universal, so it has to work with everyone: mouse, keyboard, touch; large monitors and tiny phones; screen readers; and users with motor difficulties. And existing components may not have even thought of all of these cases.
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.
1 reply →
Not Google. Microsoft, of all companies started this project: https://open-ui.org/ when Google was busy breaking the web web components, hardware APis etc.
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.
Because Google is known for holding back in order to not get too far ahead of other browsers?
<input> with <datalist> can provide a combobox
Missing part is dynamically updating the datalist in an efficient way
[dead]
In the spec custom elements can inherit from any html element you wish. Which should allow you to only have to add the bits you need to add and let the rest be handled by the native implementation.
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.
If you use a custom select, update your <datalist>, you should be good, shouldn't you?
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.
No. I need something like <option value="123"><img src="...">Mars</option> - separated internal representation and value and dynamically updated. If i can fit whole list to client memory why should i choose datalist over select?