4 ms·

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

> 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="..." />`.

Vinnl 5y ago
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.
- blowski 5y ago
  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.
  - Vinnl 5y ago
    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.
    - blowski 5y ago
      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.
      - Vinnl 5y ago
        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.

Vinnl 5y ago

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.

blowski 5y ago
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.
- Vinnl 5y ago
  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.
  - blowski 5y ago
    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.
    - Vinnl 5y ago
      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.