Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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/ https://w3c.github.io/webcomponents/spec/shadow/

https://www.webcomponents.org/ see "Browser Support"



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.


Only for HTML, not for CSS & JS. JS is handled by TC39 and CSS is still at W3C.


What happened there? I am not in the loop on this, so wouldn't mind getting some more details.


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

It boils down to complete capitulation by W3C.


Interesting stuff! Thanks for sharing :)


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


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.


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


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

[2] https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

[3] https://dev.to/webpadawan/beyond-the-polyfills-how-web-compo... and https://dev.to/webpadawan/the-journey-of-web-components-wron...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: