[csswg-drafts] [css-view-transitions-2] Nested transitions: what happens if there is a mismatch? (#10631)

noamr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-view-transitions-2] Nested transitions: what happens if there is a mismatch? ==
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 like `nearest`.

## 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:
1. new capture wins (like `view-transition-class`)
2. Old capture wins
3. Fallback to nearest common ancestor
4. Split to two groups, one with the old pseudo and one with the new pseudo. The two groups have a default transform animation that represents moving the element from the old position to the new.

## Trade-offs:
- Option (1) is consistent with `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.
- Option (2) has the opposite issue: the element would disappear and would abruptly appear at the end.
- Option (3) seems plausible and easy to understand, however would also have an abrupt effect, as all clipping would be lost for the duration of the transition and brought back at the end.
- Option (4) doesn't have an abrupt effect by default, as the old element would animate out of the old position and the new element would animate into its new position, however loses the "crossfade" effect and might be a bit more complex to implement. 

I tend to support option (4) because of the following:
- Option (3), for example, is trivial to achieve by using the common ancestor as the containing group in the first place. So having it as the default for mismatch doesn't add much value.
- Option (1) and (2) wouldn't work well (an even more abrupt effect) if the containing group has an entry/exit animation. The element would immediately disappear from the old container as the old container is fading away, and would fade in with the new element.
- Crossfade might not be the right animation here anyway. When moving between different containers, those containers can have different backgrounds, and they might crossfade between themselves. So crossfading the internal element is not necessarily the correct default, though still achievable by selecting the appropriate `view-transition-group`.





Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10631 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 26 July 2024 16:18:00 UTC