Autocomplete should have been part of HTML 20 years ago. It's incredibly frustrating how slow HTML moves when it comes to basic usability.
In my opinion, a client-side only table sorting only solves a very small unlikely niche -- so small that's not worth doing.
[EDIT] further, aside from that being a great feature for vanilla HTML even if it had continued to only be a document format, that's a great stepping stone on the way to having proper, datasource-backed tables, as is common in mature GUI widget frameworks and libraries.
A browser-based implementation would be the lowest common denominator that would likely only be used when neither style or accuracy is required. Not unlike <datalist>.
I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way.
Approaching 1?
> I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way.
This is exactly the problem, if browsers are now our LCD GUI toolkits (and they are). You absolutely should not need to do that. The proof that this is feasible is present in... well, most other major GUI toolkits. The wasted time, wasted cycles, and broken features (especially, but not exclusively, a11y) due to HTML being so bad at being the thing we're trying to make it be are all avoidable problems, not hypothetically, but in fact.
It's almost like complaining that, darn it, Windows .rc files should specify every behavior of a control, not just a few basic properties; why do we have to write custom widgets using numerous Win32 API calls and event handling cases?
And depending on what you're doing, either can be more efficient than the other.
I've seen a lot of projects try to set things up from the beginning without enough information, and it ends up falling a little flat (or worse, getting in the way).
I think a much more important endeavour is to make the browser more extensible,(like what CSS Houdini is trying to do), so you can create any kind of crazy interfaces(without having to abandon css/html completely and drop down to canvas/webgl).
What kind of autocomplete do you want? Which algorithm? What's the threshold if you're using some kind of "string distance" metric? What do you want to do style wise when you match portions of strings? What optimizations should be made for your specific case?
I don't see how a web browser is in a better position to make these types of features compared to a javascript library / web assembly.
I think some attempts at incremental improvement would be nice, maybe as the drop down gained usage that would help decide it’s future direction. Right now it’s just kinda dead and hard to use unless you’re building developer UI or something.
Design trends change, but the basic components that make up form elements have remained the same. We still have buttons, text fields, check boxes, radio buttons, etc. Those aren't going anywhere.
In practice, it's still hardly practical to use those, yet "regular" HTML has hardly evolved either.
Isn't that exactly what we have today? I want a better <select> element, I drop in Select2. I want modals, I use Bootstrap modal. And so on. Particularly with libraries like React and Vue, where we literally type `<autocomplete options="..." />`.
I can’t think how it could work differently.
<script type="html" src="better-datalist.html>
<better-datalist><!-- etc -></better-datalist>
What happens if the component is not available at runtime? Or if browser implementations ar inconsistent? It seems to me that these are the main constraints, rather than release of new standards.
But yes, there are indeed a number of limitations with that approach that result in this not being a widespread practice yet. An alternative would have been if some of the remaining elements people need would have been standardised and implemented (consistently and widespread, of course, like other standards nowadays) by browsers, but that hasn't happened either. Which means we're still dependent on framework-specific, incomplete non-standard implementations.
[1] https://developer.mozilla.org/en-US/docs/Web/Web_Components
I partially blame those who were trying to repurpose them as an application architecture framework, but primarily it's just a hard problem to solve.
Which is fine, but it's a shame that at the same time there's been practically no progress on the actually built-in elements, especially when you compare it to e.g. the amount of progress that's been made in JavaScript.
I'm sure it's due to a failure of imagination, maybe my own or maybe more widespread, but I don't actually know what you'd rather have, since it seems that there is still no concrete (even experimental) prototypes for kind of custom elements that you're envisioning. What am I missing?
- built-in elements that cover common elements like autocompletes or typeahead elements that allow e.g. the inclusion of images and formatting with their suggestions, or
- custom elements to work well enough in practice that those elements would have been created by third parties and would be widely used now.
I don't know whether the latter is actually possible, but I'm lamenting the fact that a focus on that goal seems to have coincided with hardly any attention being given to the former.
Isn't autocomplete a function of the browser, not of the markup?
Then when I start thinking about what that would mean I realize it's almost always going to be an evolution not a revolution for the following reasons...
1) No one wants to deliver two UIs, one for HTML legacy browsers, and one for the hot new browser rendering.
2) Who would own the standards? If it's a consortium we'll be back to lengthy RFPs and glacier pace of agreement, possibly resulting in something worse than HTML that does not get adopted. I can't see how any one organization could own the standard and get other browser developers to buy into it.
HTML+CSS is so integral to everyday life it's hard to see how it could ever be deprecated.
We could have this right now if iOS, Android, TVs, Windows, macOS, Linux, etc. all used HTML+CSS instead of their own toolkits. Yet they don't. Creating some fancy alternative is an even harder problem, since (a) that alternative needs to be designed and built and (b) all those same platforms will still need to switch, except we would also have to switch over the Web too.
This is a political issue, not a technology issue: it requires convincing a whole bunch of organisations to perform a costly change, for little direct benefit to them.
This would also be very easy to abuse via "embrace, extend, extinguish". Consider the history of word processors: everyone used the de facto standard (Lotus Notes) for compatibility. When Rich Text Format came along, underdogs like Word could read and write Notes-compatible documents. Once Word's market share rose, Microsoft "extended" the format so its documents could no longer be read reliably by Notes. Customers then switched to Word since it was "more reliable" at reading documents (i.e. it could handle the valid files produced by Notes, as well as the broken junk that Word produced).
Of course, Microsoft tried the same thing with HTML (badges like "Best viewed in Internet Explorer" became common precisely because IE did things in an incompatible way; I remember the relief among Web devs when IE7 came out, at its slight move towards compatibility!)
The current dominance of HTTP is largely due to firewalls, NAT, and possibly developer familiarity (e.g. proxying, debugging via cURL, etc.).
I wasn't online in the 80s, but I remember networking in the 90s being a mixture of HTTP, POP, SMTP, IRC, FTP, Telnet, NNTP, etc. The noughties saw an increase in protocols for P2P, instant messengers, etc. These days those seem to have consolidated (e.g. BitTorrent, XMPP, etc.), are often tunneled through HTTP, or are displaced by something newer which tends to use HTTP.
Services will simply offer their data with an API (and micro-transactions to use it), and then 3rd parties will create UI's for each interface.
Tweets are a useful data type, but there's nothing about twitter's brand UI that is necessary.