4 ms·
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 "part
by 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 agoI 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...