161–170 of 180 posts
Earlier quoted context omitted.
As a third party I can't help but notice that the only one doing the "shitting" here, is you.
You don't have to take only my word for it https://news.ycombinator.com/item?id=45118434
Earlier quoted context omitted.
causes a bunch of things to no longer work though - slots, style encapsulation, ...
And that's the biggest problem with Shadow DOM (and most web component specs): you can't chose the good parts. Style encapsulation is useful, slots are useful, Shadow DOM is just all around bad, having a crazy amount of edge cases and broken behaviours [1]. Can you use style encapsulation and slots without Shadow DOM? Why can't you? I only need the horse, not the horse, and the cart, and the driver, and all the cargo…
Shadow DOM was an absolute pain in reality.
Earlier quoted context omitted.
> the current advise for web components is to avoid Shadow DOM (almost like the plague) Could you provide the source for this advice?
It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only building leaf nodes so they don't need composition with slots. As soon as they try to build any kind of container element they hit big problems.
Unless you actually care about the web and its users. Then it turns out it's a very wise advice.
https://w3c.github.io/webcomponents-cg/2022.html
Web Components Community Group: 2022. You are one of the authors:
--- 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.
...
Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality
...
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.
--- end quote ---
Those are just the tip of the iceberg as these are very explicitly stated in the doc.
Then there's the issues of shifting the responsibility to both developers and consumers to handle Shadow DOM correctly.
Styling/themeing is still pain despite several different specs like shadow parts.
Don't use styles in your components too much, use Javascript to inject CSS into document and shadow trees or else there will be performance impact https://w3c.github.io/webcomponents-cg/2022.html#constructab...
Don't use too many shadow roots or there will be performance impact https://front-end.social/@5t3ph/115135994774490769 (linked in the sibling comment by @azangru)
You can't participate in forms until you write more JS for it, and still your submit buttons will be broken with no solution in sight.
etc. etc.
You don't have to take my word for it. Here's Nolan Lawson, emphasis mine:
--- start quote ---
https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibil...
Shadow DOM is a kind of retcon for the web. As I’ve written in the past, shadow DOM upends a lot of developer expectations and invalidates many tried-and-true techniques that worked fine in the pre-shadow DOM world.
--- end quote ---
Earlier quoted context omitted.
It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only building leaf nodes so they don't need composition with slots. As soon as they try to build any kind of container element they hit big problems.
> It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Unless you actually care about the web and its users. Then it turns out it's a very wise advice. https://w3c.github.io/webcomponents-cg/2022.html Web Components Community Group: 2022. You are one of the authors: --- start quote --- It's worth noting that many of these pain points are directly related to Shadow DOM's enc…
Is the better DX using lit worth the price having to deal with another library? I thought webcomponents came to enable native components and now we need another library
Earlier quoted context omitted.
> It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Unless you actually care about the web and its users. Then it turns out it's a very wise advice. https://w3c.github.io/webcomponents-cg/2022.html Web Components Community Group: 2022. You are one of the authors: --- start quote --- It's worth noting that many of these pain points are directly related to Shadow DOM's enc…
Did web components kill your dog or something? You have this truly bizarre fixation on the topic for multiple years now.
Earlier quoted context omitted.
Did web components kill your dog or something? You have this truly bizarre fixation on the topic for multiple years now.
Perhaps I care about the direction in which the web is pushed by a very small number of people incapable of seeing beyond their solutions and incapable of admitting their own mistakes.
Earlier quoted context omitted.
> the current advise for web components is to avoid Shadow DOM (almost like the plague) Could you provide the source for this advice?
It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only building leaf nodes so they don't need composition with slots. As soon as they try to build any kind of container element they hit big problems.
That's not true. Web components that render nothing will contain only their children as nodes, that's good enough for a good amount of container use cases.
So you can have something like:
...
Earlier quoted context omitted.
Did web components kill your dog or something? You have this truly bizarre fixation on the topic for multiple years now.
Perhaps I care about the direction in which the web is pushed by a very small number of people incapable of seeing beyond their solutions and incapable of admitting their own mistakes.
I had lit in a project at work and not having to deal with it anymore is just great. We already have another heavier component framework to do the actual application stuff anyway, so having two just because somebody wanted to optimize their resume was such a drag. It all looked nice in theory, but one thing shadow DOM makes worse is A11y, because element ids are now scoped and all the missing describe-by, label-for f…
Does this actually happen a lot? Allowing for the fact that people would rarely admit to it just being about resume padding, I feel like just wanting to _use_ the thing is a far more common motivation for poorly rationalised technology choices.