Re: [csswg-drafts] [css-shared-element-transitions-1] Pseudo-element selectors for shared element transitions (#7743)

I have some questions about shadow DOM and this API:

1. Special replaced elements: Currently in the pseudo element model, we have replaced elements that are specced to reflect either a captured snapshot or "live" dom, depending on the situation and that's just "magic" in the sense that particular pseudo element names are defined to be these elements. We're fairly safe in making these definitions because the developer has no way to also create these elements, they are limited to UA control. If we switch to shadow DOM, what elements would we use? I can see that the example above uses `div`s with some part attributes, but presumably that would mean that the developer can also create these `div`s with these attributes in the light dom or in their own shadow doms. Is there any way to preclude that? In other words, is it possible to have some "magic" element that the UA can add but that the developers can't, when it comes to shadow DOM? Just having a new element also seems insufficient since nothing is preventing the developers from creating new elements either

2. Element references: if we use shadow DOM, we also want to make sure that the developer can't reparent these elements or in general get a reference to them, other than selecting them for style via CSS selectors. I assume there is precedence for that, but I just wanted to make sure that this is already an established practice.

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. We would require something along the lines of a wrapper div right inside the shadow dom to act as a "root" for the purposes of this API. That seems like an ergonomics challenge for developers. I wonder if there are any elegant solutions here



-- 
GitHub Notification of comment by vmpstr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7743#issuecomment-1248416144 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:47:28 UTC