[jacob019]

The shadow DOM can inherit styles if you specify the styles that you want to inherit. Additionally, web components work just fine without the shadow DOM, it's optional, but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.

[kerkeslager]

> The shadow DOM can inherit styles if you specify the styles that you want to inherit.

Ah yes, I've heard about this "mixing CSS into your HTML".

The entire point of CSS is that you can write selectors that can affect anything, import it in the header, and you're done. If you're telling me I have to import a new CSS file (or repeat myself and import the same CSS file) inside of every custom element I create, obviously I thought of that. I'm telling you that's a terrible, awful idea, because it breaks the fundamental way CSS is supposed to work.

Consider: if I'm distributing a library of web components, which of my users' CSS files that I know nothing about do I include? Did you read the example I already gave? The solution you're offering doesn't solve the problem I've described.

> Additionally, web components work just fine without the shadow DOM, it's optional,

You should read the post you're responding to in order to find out why that also causes problems.

> but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.

...just like all of the rest of CSS. We have strategies for dealing with that. The only strategy you've suggested for doing the opposite is a completely useless non-solution.

[azangru]

> Consider: if I'm distributing a library of web components, which of my users' CSS files that I know nothing about do I include?

If you are distributing a library of web components, wouldn't you provide a CSS api for the things that are supposed to be styleable via CSS custom properties and styleable parts?

Case in point: consider Shoelace.

> a completely useless non-solution

Consider the existing libraries of web components — Shoelace for something generic, RedHat's Patternfly or Adobe's Spectrum for something company-specific. How much of a non-solution are they, really?

[kerkeslager]

> If you are distributing a library of web components, wouldn't you provide a CSS api for the things that are supposed to be styleable via CSS custom properties and styleable parts?

If you read my previous comments you'll see that the parts that should be styleable--i.e. the content of the component I've defined--are user-defined, so no, I can't document them.

> Consider the existing libraries of web components — Shoelace for something generic, RedHat's Patternfly or Adobe's Spectrum for something company-specific. How much of a non-solution are they, really?

If you read what I said in context, I'm not saying components are useless, I'm saying the unstyled shadow DOM is a completely useless non-solution to the problem I've described.

[s17n]

> I'm telling you that's a terrible, awful idea, because it breaks the fundamental way CSS is supposed to work.

The "way CSS is supposed to work" was always a bad idea and is totally unworkable for large projects / teams. Throwing it out and simply inlining all your styles is absolutely the right call.

[kerkeslager]

Eh, there's some validity to that, but the worst of both worlds is to have both a CSS file and then a bunch of inline styles, which is what people here are proposing.

Inline styles make a lot of sense if you're using webcomponents pervasively, but there's a high up-front cost to doing that because you'll have to either a) define web components for everything you might want to style, including existing elements like <p>, or b) repeat yourself a lot.

[webstrand]

Without the shadow dom, though, what really is the difference from just using `<div>` elements? You can't use slots, you're vulnerable to bad `querySelector`s, events aren't isolated, and you get none of the performance benefits.

I've tried to find a workable solution using style inheritance, but it doesn't work everywhere. On code sandbox sites like codepen.io, the stylesheet is generated for you and sometimes updated in-place. You'd have to watch with a MutationObserver and then propagate the change to every instance of a custom element on the page.

[kerkeslager]

> You'd have to watch with a MutationObserver and then propagate the change to every instance of a custom element on the page.

This solution works in that you can create a mixin that does this and use it in your custom elements. But if you profile it I think you'll discover it's painfully slow. It's not noticeable if you're using a few custom elements here and there, but if you're, for example, making a table of custom elements, the page will load slowly.

[webstrand]

Yeah, that's exactly my experience. I built a framework for quickly prototyping with web components before I discovered the CSS-isolation defect. Sadly it's pretty much killed that idea as unworkable.

<https://codepen.io/webstrand/pen/jOzYVpL> is as far as I got. The FOUS is pretty annoying, too, before the templates get properly registered. But I could live with that.

[azangru]

> Without the shadow dom, though, what really is the difference from just using `<div>` elements?

Having a lifecycle that you can hook into to know when to run code related to this particular instance of the custom element.

See e.g. a recent talk on web components — https://youtu.be/jBJ7eoPtmY8?t=367

[vanake]

probably what GP meant there is now way to inherit styles without specifing which styles you want to inherit. There should option shadow dom inherit all styles.