- From: Greg Whitworth <notifications@github.com>
- Date: Wed, 14 Feb 2024 09:49:11 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1049/1944314660@github.com>
First, thank you @shannonmoeller for filing the issue +1 to @justinfagnani and @caridy points on the issues discussed to @shannonmoeller proposal My overall opinion on this has changed over the years and I agree with this statement by @ox-harris > Put another way, haviing the Shadow DOM as the one means to those ends is what I see as the problem. I would actually recommend the inverse of this and say we should try and figure out how to bring custom elements **with** `<slots>` into the light DOM rather than opening up shadow DOM boundaries beyond what is available via the `mode` switch. This also aligns with @ox-harris other point that we're continuing to solve within the Light DOM other problems we originally used shadow DOM for (eg: scoped styles). I've raised this in the past so I know there is a can of worms for supporting `slots` without a shadow tree but I foresee that being a better DX. In either scenario though, I am curious how a developer would know which capabilities they have when consuming someone else's component without resorting to Javascript which speaks to @caridy point of the potential matrix we have? This is important to consider if I'm using someone else's web component and all I want to do is cross reference an ID or style a child; how do I easily know that's possible? I digress. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1049#issuecomment-1944314660 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1049/1944314660@github.com>
Received on Wednesday, 14 February 2024 17:49:18 UTC