- From: Lea Verou <notifications@github.com>
- Date: Sun, 20 Jul 2025 15:52:11 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1108/3094841853@github.com>
LeaVerou left a comment (WICG/webcomponents#1108) Thank you both. I was aware that this was considered for v0, but didn't recall the details as I wasn't as involved then. However, so much has changed since then, I thought it was worth revisiting, hopefully in a way that keeps complexity at bay (the design @justinfagnani is describing indeed seems excessively complex to me). I was not aware of the alternative design from 2014 @rniwa is linking to. @rniwa how do you feel this compares to the state of WC today? Are there elements of this proposal that may be worth revisiting? Additionally, using slots rather than a special element means you get a lot of existing (and future) slot API for free, without having to redefine it for `<shadow>`. And it seems closer to the current workaround of wrapping the native element (which essentially also nests shadow roots, just just also have the shadow host and you can't get access to any JS properties/methods. Special slots are also more extensible, e.g. see the `type="super"` idea. One could even conceive of entirely different types of slots down the line, e.g. slots going the other way, allowing the component to insert content in certain slots of its light DOM. OTOH, perhaps a dedicated element could allow adopted style sheets without a shadow root, minimizing the number of cases one needs to wrap the parent's shadow root. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1108#issuecomment-3094841853 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1108/3094841853@github.com>
Received on Sunday, 20 July 2025 22:52:15 UTC