12 ms·

> is there any effort to do the same thing in a non-scoped way? It's already done! Web Components (Custom Elements + Shadow DOM) are web standards, ratified by

> is there any effort to do the same thing in a non-scoped way? It's already done! Web Components (Custom Elements + Shadow DOM) are web standards, ratified by W3C, and they already work great in Firefox and Safari. This whole article is simply incorrect. http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/ https://w3c.github.io/webcomponents/spec/shadow/ https://w3c.github.io/webcomponents/spec/shadow/ https://www.webcomponents.org/ https://www.webcomponents.org/ see "Browser Support"

dmitriid 7y ago
They... don't work great. They cannot be serialized, they break accessibility, they break screen readers (AFAIR), they are not lazy loaded, they do not participate in form events, they...
- dfabulich 7y ago
  They require JS, which is definitely a drawback. But they work fine in screen readers, (you can screw this up with JS, just like any other HTML) and they "participate" in form events just like other HTML. Since they require JS, you can lazy load them if you want (it's just JS).
  - dmitriid 7y ago
    I don't know the state of it today, but even in summer last year custom components with Shadow DOM were still excluded from Form Submission. Form-associated custom elements proposal was enabled in Chrome, no idea if Safari or Firefox went and implemented it, too. Shadow DOM also throws off accessibility IIRC if aria-labeledby and similar cross shadow dom boundaries [1] but I do agree they should be largely accessible to assistive technologies. You can't truly lazy-load them. See Rich Harris' (author of Svelte) take on Web Components [2] And these two articles by a Web Components proponent listing the many issues they still have [3] [1] See for example this tweet https://twitter.com/sarahmei/status/1198069119897047041 https://twitter.com/sarahmei/status/1198069119897047041 [2] https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... [3] https://dev.to/webpadawan/beyond-the-polyfills-how-web-components-affect-us-today-3j0a https://dev.to/webpadawan/beyond-the-polyfills-how-web-compo... and https://dev.to/webpadawan/the-journey-of-web-components-wrong-ways-lacking-parts-and-promising-paths-1d5a https://dev.to/webpadawan/the-journey-of-web-components-wron...
- true_religion 7y ago
  Screen readers and accessibility software have never worked well* with arbitrary applications, and that’s what sites using the shadow dom aim to be. Screen readers especially only do well on simple documents, and only work with apps well they’re specifically designed to interface with which for the most part are apps that are used in document creation or text communication like Word, or Skype. *Disclaimer: “well” is in the eye of the beholder. It’s challenging to use them with arbitrary apps, and the time investment is only useful if that app is going to put food into your table.
ChrisSD 7y ago
I would note that "ratified by W3C" does not mean much nowadays. WHATWG won that war and the W3C now essentially rubber stamps whatever WHATWG decides.
- throwaway77384 7y ago
  What happened there? I am not in the loop on this, so wouldn't mind getting some more details.
  - ChrisSD 7y ago
    When W3C's XHTML 2.0 stalled WHATWG created a new "living standard" (which is subject to constant modifications and additions) to continue HTML development. W3C attempted to create fixed standards from the document (e.g. HTML 5.1, HTML 5.2, etc) that only included things that were widely supported and that met standards for accessibility and so on. However, due to the constant churn of WHATWG's document this was difficult and WHATWG were strongly against having what they saw as competing standards. Therefore there was some conflict between the two groups until WHATWG emerged victorious. Here's the final agreement: https://www.w3.org/2019/04/WHATWG-W3C-MOU.html https://www.w3.org/2019/04/WHATWG-W3C-MOU.html It boils down to complete capitulation by W3C.
- SahAssar 7y ago
  Only for HTML, not for CSS & JS. JS is handled by TC39 and CSS is still at W3C.
throwaway77384 7y ago
Interesting stuff! Thanks for sharing :)

dmitriid 7y ago

They... don't work great. They cannot be serialized, they break accessibility, they break screen readers (AFAIR), they are not lazy loaded, they do not participate in form events, they...

dfabulich 7y ago
They require JS, which is definitely a drawback. But they work fine in screen readers, (you can screw this up with JS, just like any other HTML) and they "participate" in form events just like other HTML. Since they require JS, you can lazy load them if you want (it's just JS).
- dmitriid 7y ago
  I don't know the state of it today, but even in summer last year custom components with Shadow DOM were still excluded from Form Submission. Form-associated custom elements proposal was enabled in Chrome, no idea if Safari or Firefox went and implemented it, too. Shadow DOM also throws off accessibility IIRC if aria-labeledby and similar cross shadow dom boundaries [1] but I do agree they should be largely accessible to assistive technologies. You can't truly lazy-load them. See Rich Harris' (author of Svelte) take on Web Components [2] And these two articles by a Web Components proponent listing the many issues they still have [3] [1] See for example this tweet https://twitter.com/sarahmei/status/1198069119897047041 https://twitter.com/sarahmei/status/1198069119897047041 [2] https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... [3] https://dev.to/webpadawan/beyond-the-polyfills-how-web-components-affect-us-today-3j0a https://dev.to/webpadawan/beyond-the-polyfills-how-web-compo... and https://dev.to/webpadawan/the-journey-of-web-components-wrong-ways-lacking-parts-and-promising-paths-1d5a https://dev.to/webpadawan/the-journey-of-web-components-wron...
true_religion 7y ago
Screen readers and accessibility software have never worked well* with arbitrary applications, and that’s what sites using the shadow dom aim to be. Screen readers especially only do well on simple documents, and only work with apps well they’re specifically designed to interface with which for the most part are apps that are used in document creation or text communication like Word, or Skype. *Disclaimer: “well” is in the eye of the beholder. It’s challenging to use them with arbitrary apps, and the time investment is only useful if that app is going to put food into your table.

ChrisSD 7y ago

I would note that "ratified by W3C" does not mean much nowadays. WHATWG won that war and the W3C now essentially rubber stamps whatever WHATWG decides.

throwaway77384 7y ago
What happened there? I am not in the loop on this, so wouldn't mind getting some more details.
- ChrisSD 7y ago
  When W3C's XHTML 2.0 stalled WHATWG created a new "living standard" (which is subject to constant modifications and additions) to continue HTML development. W3C attempted to create fixed standards from the document (e.g. HTML 5.1, HTML 5.2, etc) that only included things that were widely supported and that met standards for accessibility and so on. However, due to the constant churn of WHATWG's document this was difficult and WHATWG were strongly against having what they saw as competing standards. Therefore there was some conflict between the two groups until WHATWG emerged victorious. Here's the final agreement: https://www.w3.org/2019/04/WHATWG-W3C-MOU.html https://www.w3.org/2019/04/WHATWG-W3C-MOU.html It boils down to complete capitulation by W3C.
SahAssar 7y ago
Only for HTML, not for CSS & JS. JS is handled by TC39 and CSS is still at W3C.

throwaway77384 7y ago

Interesting stuff! Thanks for sharing :)