3 ms·

> this seems like a necessary step towards standards-based development Which standards? I keep saying: even web components people finally admitted that they n

by troupo 3y ago

> this seems like a necessary step towards standards-based development Which standards? I keep saying: even web components people finally admitted that they need 20 more standards to solve issues (largely caused by web components themselves) that literally no other framework has: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html There's a reason very few frameworks (including the new ones) target web components by default and do their own thing. And their authors have been very clear as to why (think Svelte, Vue, Solid etc.).

ruined 3y ago
just glancing over this doc, it seems like a lot of these are problems currently ignored by existing frameworks and solved by bundlers, and the remainder of them were problems that each framework addressed independently after years of development
- troupo 3y ago
  > t seems like a lot of these are problems currently ignored by existing frameworks They are not ignored. They just don't exist or, indeed, are solved by other, better means (or indeed better web specs like CSS scoping etc.). Let me quote directly from the doc: --- start quote --- It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers. --- start quote --- To put simply, "many of these problems exist only because web components exist, and they are so bad that developers actively avoid web components and seek other solutions". Here is a list of issues that literally don't exist anywhere except web components (so there's nothing to ignore): - Composed Selection "Since existing Selection APIs can represent only a single selection in a document, bound to a single Range, the need for an API to represent ranges over a composed tree has been generally acknowledged since at least 2015." - Constructable Stylesheets & adoptedStyleSheets The only way for web components can share stylesheets without duplicating them - Cross-root ARIA "Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM." - CSS Properties and values inside shadow root - Anything related to declarative templates: Declarative CSS Modules, Declarative Custom Elements, Declarative Shadow DOM - DOM Parts "Enable batched updates to the DOM, usable by library/framework view engines." This is actually useful. Why the hell it's tied to Web Components? No one knows. But yeah, all/most frameworks have a solution to this, and web components are useless as a foundation for web frameworks without it - Form-Associated Custom Elements Yup, you still can't make a custom button that behaves like a submit button in web components - Lazy custom element definitions Web components are eagerly rendered whether you want it or not. I don't think there's a single framework that doesn't have lazy loading/rendering/rendering on demand - Open styling of shadow roots - Styling children of slotted content - Theming
  - esprehn 3y ago
    Fwiw custom buttons that submit are possible: https://webkit.org/blog/13711/elementinternals-and-form-associated-custom-elements/ https://webkit.org/blog/13711/elementinternals-and-form-asso... I think you're looking for internals.form.requestSubmit()
    - troupo 3y ago
      You're absolutely correct. (For reference, here's a long discussion in an issue: https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814)

by troupo 3y ago

ruined 3y ago

just glancing over this doc, it seems like a lot of these are problems currently ignored by existing frameworks and solved by bundlers, and the remainder of them were problems that each framework addressed independently after years of development

troupo 3y ago
> t seems like a lot of these are problems currently ignored by existing frameworks They are not ignored. They just don't exist or, indeed, are solved by other, better means (or indeed better web specs like CSS scoping etc.). Let me quote directly from the doc: --- start quote --- It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers. --- start quote --- To put simply, "many of these problems exist only because web components exist, and they are so bad that developers actively avoid web components and seek other solutions". Here is a list of issues that literally don't exist anywhere except web components (so there's nothing to ignore): - Composed Selection "Since existing Selection APIs can represent only a single selection in a document, bound to a single Range, the need for an API to represent ranges over a composed tree has been generally acknowledged since at least 2015." - Constructable Stylesheets & adoptedStyleSheets The only way for web components can share stylesheets without duplicating them - Cross-root ARIA "Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM." - CSS Properties and values inside shadow root - Anything related to declarative templates: Declarative CSS Modules, Declarative Custom Elements, Declarative Shadow DOM - DOM Parts "Enable batched updates to the DOM, usable by library/framework view engines." This is actually useful. Why the hell it's tied to Web Components? No one knows. But yeah, all/most frameworks have a solution to this, and web components are useless as a foundation for web frameworks without it - Form-Associated Custom Elements Yup, you still can't make a custom button that behaves like a submit button in web components - Lazy custom element definitions Web components are eagerly rendered whether you want it or not. I don't think there's a single framework that doesn't have lazy loading/rendering/rendering on demand - Open styling of shadow roots - Styling children of slotted content - Theming
- esprehn 3y ago
  Fwiw custom buttons that submit are possible: https://webkit.org/blog/13711/elementinternals-and-form-associated-custom-elements/ https://webkit.org/blog/13711/elementinternals-and-form-asso... I think you're looking for internals.form.requestSubmit()
  - troupo 3y ago
    You're absolutely correct. (For reference, here's a long discussion in an issue: https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814)