> so that we would no longer have to wait on web standards to evolve

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 mean, sure, but we've always had that - but having widely-supported elements that are as good as the built-in elements with accessibility support and all, and have no dependencies and no requirements on a particular application architecture or framework use would certainly be nice.

I’m not sure I understand what you’re thinking of. If it’s native to one browser, then usage is restricted. To allow different browsers to use it means standards like we already have. JavaScript is the means by which websites can augment the browser with their own functionality - dependencies make it easier for developers to do this, but are not necessary. Plugins allow users to do the same.

I can’t think how it could work differently.

It means standards like were newly developed under the Web Components umbrella. The idea was that you could do something like

    <script type="html" src="better-datalist.html>

and then you'd be able to use e.g.

    <better-datalist><!-- etc -></better-datalist>

regardless of whether you're using one framework or another, and without adding heaps to your payload.

So the browser comes with opt-in native controls that a page can enable. Is that right?

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.

Not quite; you (or rather, third parties properly maintaining them) can define your own components (i.e. in `better-datalist.html`) that you would then be able to use.

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.

How do web components[1] fail to be the custom elements you imagined?

[1] https://developer.mozilla.org/en-US/docs/Web/Web_Components

It is what Web Components were supposed to be, but they're not living up to that yet. They're reliant on client-side JavaScript, have special needs that cause them not to be well-integrated in the most widely-used JS framework yet, and have a number of other issues - as evidenced by the fact that there's still not a custom element that basically solves the mentioned limitations of Data Lists and is widely used and can be counted on to be as well-done as native elements in areas like accessibility.

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 probably ignorant: is there an example of any kind of custom element, in 2012 or now, with customization (nevermind CSS styling) that does not depend on JavaScript?

No, that's one of their limitations. (Well, styling can be done to some extent with CSS variables and the shadow DOM, I think.)

Ok, so as someone new-ish to web programming, how should I understand the current relevance of 2012's Extensible Web Manifesto, and the dissatisfaction you're expressing about <datalist> and about Web Components?

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?

So I'd prefer either:

- 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.