- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Sep 2022 17:58:17 +0000
- To: public-css-archive@w3.org
> 1\. is it possible to have some "magic" element that the UA can add but that the developers can't I think we can explain this via the cascade. The image stuff only works when it's in this particular shadow DOM. > 2\. we also want to make sure that the developer can't reparent these elements or in general get a reference to them That seems bad. One of the advantages of using shadow DOM would be allowing developers to get regular element references. Without this, we'll still have to go down the path of creating pseudo-element references, and it's not even clear if that should work for `::part`. > 3\. Scoped transitions: lastly, and this is outside of the scope of the current spec, but one future improvement that we've talked about for this API is scoping the transition to a subtree. Basically, since only one transition is allowed and that transition occupies the whole document, it makes it awkward to use in something like reusable components. For that, we'd like to work towards scoping the pseudo/shadow dom structure to be attached to an element other than html via some properties/js api calls and limit the transition to a subtree. Now, there are other technical challenges here, but if we switch to shadow dom it also adds another one: we wouldn't be able to attach this shadow dom to a custom element which already has a developer shadow dom attached. Yeah, this is a huge issue. But similarly, it also seems weird that SET gets to claim the shadow DOM of the root element. Like, do we just get to own that space since we arrived first? This is why, when I was thinking about doing this via shadow DOM, I suggested that the shadow root be attached to a pseudo-element. That's new and weird though. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7743#issuecomment-1248426056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 September 2022 17:58:19 UTC