calinoracation
commented
6 months ago Here's an example I've run into that illustrates the problem well. In this instance each of these "chips" is its own shared element. I would love for an automatic clip path to be applied to each of them so that the fade out or fade in would match the appearance on screen by default.
https://github.com/w3c/csswg-drafts/assets/23196205/1945f2ea-8e15-41e4-b85d-2ae6c6daddf9
I've mentioned this before but having access to the dimensions through something like an env(<view-transition-name, width) or something like that would be super ideal. Automatic clip-path based on the scroller here is our 90% use case and would do most of what we want, but there are also other use cases. Having the data the API is already using would give us more capabilities in general to do custom variations on the clip-path, or translate only if something is just moving on the x/y coordinates and we can guarantee size isn't changing between the 2 items to be able to get a bit of a performance boost. Even to just override the default animation with a bit of a different default.
That's all just extra, the automatic clipping you are suggesting would already be a huge win given the large amount of scroll containers and clipping in current web apps.
In v1, participating elements escape ancestor clip. This means for example, that clipping the entire document with a circle
clip-pathand then transitioning between elements inside it, the circle clip would disappear during the transition.This can be manually fixed by applying a clip-path to the transition pseudo-element, but perhaps we can do a better job at this automatically - coalesce the transformed ancestor paths for a captured element, and apply it as a clip path to the pseudo element. Not sure if this would produce better results than the nested transition group proposal but I thought I should raise this for discussion so that the use cases is considered.