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.