Open noamr opened 1 month ago
//cc @khushalsagar @vmpstr @flackr @fantasai @nt1m
I just ran into this while working on a site and I'd like to propose a modified version of option 3:
Creating a pseudo common ancestor that has a clipping shape that includes both containers and the space between them, somewhat like this:
This would avoid the moving child popping in or out on the opposite end of the containers.
One thing I'm not sure on is the exact shape of the ancestor since the clipping boundaries of the two containers might not be square. Ideally, the pseudo-ancestor would have its exact shape determined by some sort fill between the two containers that leaves their far edges as they are and only includes the space between that an element would be travelling through. I think the most common problem would be rounded corners and maybe more fancy, nine-sliced corners/edges.
Also, here's my real-world example of this causing issues:
One thing I'm not sure on is the exact shape of the ancestor since the clipping boundaries of the two containers might not be square. Ideally, the pseudo-ancestor would have its exact shape determined by some sort fill between the two containers that leaves their far edges as they are and only includes the space between that an element would be travelling through. I think the most common problem would be rounded corners and maybe more fancy, nine-sliced corners/edges.
Also, here's my real-world example of this causing issues:
CrossUniverseClipping.webm
Thanks for this! I am not sure how we can translate this into a solution though.
Note that clipping is just one example, there is also opacity blending and filters.
My current thinking is that "last capture wins" is the simplest and more consistent with existing stuff, especially since "nearest common ancestor" is trivial to achieve by using that ancestor in view-transition-group
.
My current thinking is that "last capture wins" is the simplest and more consistent with existing stuff, especially since "nearest common ancestor" is trivial to achieve by using that ancestor in view-transition-group.
Agreed
My current thinking is that "last capture wins" is the simplest and more consistent with existing stuff
By "last capture wins" I think you mean we use the ancestor based on the new DOM? How do we deal with a case where the new element uses an ancestor which is not in the old element's ancestor chain? We have to figure out what the old transform should be in this case.
I'm not opposed to this idea but stuff like the above seems easier to reason about with "least common ancestor". Since you can always map the cached old transform to any ancestor. The fallback is more like the default flat mode.
My current thinking is that "last capture wins" is the simplest and more consistent with existing stuff
By "last capture wins" I think you mean we use the ancestor based on the new DOM? How do we deal with a case where the new element uses an ancestor which is not in the old element's ancestor chain? We have to figure out what the old transform should be in this case.
The old element will save the final transform, and we'll project to be relative to the final parent.
I'm not opposed to this idea but stuff like the above seems easier to reason about with "least common ancestor". Since you can always map the cached old transform to any ancestor. The fallback is more like the default flat mode.
Is there more stuff like the above?
The old element will save the final transform, and we'll project to be relative to the final parent.
Ah, so figure out its transform relative to the root and map it into the chosen ancestor's space. Makes sense.
Is there more stuff like the above?
Everything else which is hierarchical (opacity, clip). If these effects are on the LCA then using that will look more correct. Though if they are on any node between the LCA and the new named element and we choose LCA then new would look wrong.
So I'm fine with both. As you said, if this doesn't work authors can always fix it by using the LCA as the parent explicitly.
The old element will save the final transform, and we'll project to be relative to the final parent.
Ah, so figure out its transform relative to the root and map it into the chosen ancestor's space. Makes sense.
Is there more stuff like the above?
Everything else which is hierarchical (opacity, clip). If these effects are on the LCA then using that will look more correct. Though if they are on any node between the LCA and the new named element and we choose LCA then new would look wrong.
Opacity & clip are different from transform in that sense. They would be applied on the parent element, which would clip/mask the whole layer underneath. In some cases it would look different from the original state, but there is no way around it (except for putting view-transition-group: nearest
on everything.
So I'm fine with both. As you said, if this doesn't work authors can always fix it by using the LCA as the parent explicitly.
Cool
Follow up on #10334 (nested transitions)
It's clear what happens when both the old and new state have the same
view-transition-group
. We need to specify, however what happens when there is a mismatch. Note that this mismatch can happen by use of keywords likenearest
.Example:
A box sliding between two clipping containers![BoxToBox](https://github.com/w3c/csswg-drafts/assets/88566/51fe0056-173a-443e-87ff-00c009f1ad10)
Several solutions to a mismatch:
view-transition-class
)Trade-offs:
view-transition-class
, however can create an abrupt experience: in the attached example, the element would disappear at the beginning of the transition and would animate in later.I tend to support option (4) because of the following:
view-transition-group
.