4 ms·

Most painful is that the idea was [1] that the web would be extended with the ability to create your own custom elements so that we would no longer have to wait

by Vinnl 5y ago

Most painful is that the idea was [1] that the web would be extended with the ability to create your own custom elements so that we would no longer have to wait on web standards to evolve. In practice, it's still hardly practical to use those, yet "regular" HTML has hardly evolved either. [1] https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/

blowski 5y ago
> 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.
an1sotropy 5y ago
How do web components[1] fail to be the custom elements you imagined? [1] https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components
- Vinnl 5y ago
  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.
  - an1sotropy 5y ago
    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?
    - Vinnl 5y ago
      No, that's one of their limitations. (Well, styling can be done to some extent with CSS variables and the shadow DOM, I think.)
      - an1sotropy 5y ago
        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?

by Vinnl 5y ago

blowski 5y ago

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

an1sotropy 5y ago

How do web components[1] fail to be the custom elements you imagined? [1] https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components

Vinnl 5y ago
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.
- an1sotropy 5y ago
  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?
  - Vinnl 5y ago
    No, that's one of their limitations. (Well, styling can be done to some extent with CSS variables and the shadow DOM, I think.)
    - an1sotropy 5y ago
      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?