[csswg-drafts] [css-view-transitions-1] Define the constraints which must be satisfied by a named element during the transition (#8548)

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

== [css-view-transitions-1] Define the constraints which must be satisfied by a named element during the transition ==
#8139 resolved on the exact constraints we need on a named element in View Transitions and the fact that they are implicitly applied by view-transition-name. #7882 resolved that if constraints on the element are unsatisfied during the animation, we should abort the transition.

As the spec changes for these were being landed in #8540 we realized we need a more precise resolution on how the constraints are checked. Here's the list:

1. Any [=flat tree=] ancestor of |capturedElement|'s [=new element=] [=skips its contents=].
2. |capturedElement|'s [=new element=] is [=element-not-rendered|not rendered=].
3. |capturedElement|'s [=new element=] does not form a [=stacking context=].
4. |capturedElement|'s [=new element=] does not form a [[css-transforms-2#grouping-property-values|group]].
5. |capturedElement|'s [=new element=] does not form a [=backdrop root=].

#2 was explicitly spelled out [here](https://github.com/w3c/csswg-drafts/issues/7882#issuecomment-1377660423): "The element must have an associated box."

#1 states that the element's contents should not be skipped, for example via `content-visibility: hidden`. We ignore named elements which skip their contents when capturing the new state [here](https://drafts.csswg.org/css-view-transitions-1/#capture-new-state-algorithm), see 3.1. So this check makes sure the developer doesn't modify their CSS to make the element skip its contents once the transition starts. `content-visibility: auto` could have caused the element to skip its contents without a change from the developer, but the resolution [here](https://github.com/w3c/csswg-drafts/issues/8060#issuecomment-1411189366) ensures that once a named element is participating in a transition it is forced to stay relevant to the user.

#3, #4 and #5 are constraints we resolved on in #8139 but the question is do we check for these constraints explicitly or enforce that the computed value of `view-transition-name` for an element participating in a transition is not none or doesn't change at all. The second option achieves the same effect since having the property will continue to apply any requisite constraints.

**My opinion**
If the developer had CSS, outside of view-transition-name, that was applying these constraints. Suddenly a seemingly unrelated change will break their transition. I can imagine a developer going: "setting opacity seems to make this work, Idk why". So enforcing that you don't remove view-transition-name until the animations are done makes the CSS that the feature relies on less brittle.

@jakearchibald @vmpstr @tabatkins FYI.

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


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

Received on Thursday, 9 March 2023 00:22:44 UTC