Slots and Shadow Dom (web-components)

[acroyear]

In https://preactjs.com/guide/v10/web-components/#passing-slots-as-props - why can named slots only be used with shadow dom? I am using a style framework that is 'global', meaning if I use shadow dom on any web components, lots of the styles are lost including how it uses <i> for icons. (Specifically, beercss).

I know I can work around it by just taking the children array and splitting them among my own component's children, but I'd rather use the standard. I also know preact components slots without shadow can be done conceptually, as Oracle JET has done that.

So curious what the limitation is at this time.

[rschristian]

Probably better asked on the preact-custom-element repo but I see we don't have discussions enabled there. An issue would probably be fine.

why can named slots only be used with shadow dom?

I believe slots are inherently limited to within shadow roots? I don't think that can function any other way whilst following the platform.

Oracle JET might provide some wrapping there but I don't think we would.

[acroyear]

ok lit-element and stencil have it, and this https://www.webcomponents.org/element/slotted-element kind of hacks it in as well. basically they take the children and look for the slot names attributes and manipulate the html after first render.

granted in preact that gets trickier because you have to rely on ref functions to be told when the children are rendered in order to move them to their appropriate locations in the DOM you're creating...which means maybe a component that manages internal portals may be a better solution. the idea is to make it transparent - this is an app that's actually going to be handling multiple different web-component building libraries, and yeah, the whole point of web-components is standards-level interchangeability. :)

well, then there's https://gomakethings.com/the-shadow-dom-is-an-antipattern/ which i concur with quite a bit, but here we are.

thanks for the feedback.