[css-view-transitions-1] Define the constraints which must be satisfied by a named element during the transition

[khushalsagar]

#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: "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, 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 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.

[jakearchibald]

My opinion: view-transition-name is used to determine which elements are captured to form old/new views, and it applies the required constraints as a convenience. However, the functionality of view-transition-name (aside from the application of constraints) doesn't apply throughout the transition.

Assuming the element is rendered & not skipped, a view-transition-name of not-none will enforce the constraints we require. However, I chose not to use it has a proxy, because at this stage we're kinda 'done' with view-transition-name.

For example, once we capture the view-transition-name as foo, it creates a foo group. If you change the view-transition-name to bar half way through the transition, nothing happens, it's still part of the foo group, since that decision was made at capture time.

If we make view-transition-name part of the requirements during the transition, we'd only be doing so in a weird half way. As in, we'd only be requiring view-transition-name to be set to any non-none value.

We decided against making view-transition-name part of the checks here. Although it would be cheap to check the view-transition-name hasn't changed for captured elements (and skip otherwise), it'd be more expensive to check if any new view-transition-names have appear, per frame.

That said, my feelings here aren't super strong.

[vmpstr]

I mentioned it on the related PR, but I'll mention it here for posterity: I don't believe that requiring the constraints 3, 4, and 5 is equivalent to requiring view-transition-name non-none value since the latter also requires the view-transition-name to have a non-none value for the duration of the animation. That was not a constraint we've resolved to have.

Having this extra constraint seems to put a limit on what a developer can do while the animation is happening. They, for example, can't remove view-transition-names to set up the next part of the view transition. (That's the only example I can think of, btw)

My opinion is that a view-transition-name non-none value is a convenient way to ensure that all constraints are satisfied, but it should itself not be a requirement. If a developer chooses to satisfy the constraints 3, 4, and 5 in ways other than view-transition-name non-none value, that should be fine. If the developer needs another convenience CSS (aside from view-transition-name) to make sure the requirements are satisfied, then they can probably use one of the will-change values or maybe we can add another will-change value if none of the existing ones are sufficient

[jakearchibald]

Summary for CSSWG meeting:

Previous resolution: A view-transition-name value that isn't none gives an element stacking context, grouping element, backdrop root, similar to non-1 opacity, as view transitions need these constraints.

The value of view-transition-name is only consulted during the setup of the view transition, to decide which elements should be involved in the transition. However, because the ::view-transition-new view is 'live', the constraints need to be checked per frame.

Previous resolution: If constraints are broken mid-transition, the rest of the transition is skipped.

There are additional constraints per-frame that aren't covered by view-transition-name, such as the element being rendered. These aren't constraints during the setup of the transition, as these constraints simply result in the element being ignored.

The question is, how should we check these conditions are met per frame?

Option 1: Assert the additional conditions, such as "rendered", then assert the remaining conditions by checking the view-transition-name is not none.

This means removing the view-transition-name from a transitioning element mid-transition would skip the transition. However, setting the view-transition-name to another value has no effect - it wouldn't change the transition group of the element. We're only concerned with the side-effects of view-transition-name.

Option 2: Assert all of the conditions individually, regardless of view-transition-name.

This means removing the view-transition-name from a transitioning element mid-transition would skip the transition, unless the constraints are satisfied by other means, such as a non-0 opacity.

We're split on this, so help us decide 😄. The outcome of #8339 might be a deciding factor.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] Define the constraints which must be satisfied by a named element during the transition, and agreed to the following:

• RESOLVED: If an element is involved in a transition, the `view-transition-name` constraints are enforced during the transition
• RESOLVED: Conditions are checked per-frame; transition is skipped if other constraints are broken

The full IRC log of that discussion

<JakeA> A view-transition-name value that isn't none gives an element stacking context, grouping element, backdrop root, similar to non-1 opacity, as view transitions need these constraints.
<emeyer> JakeA: If you give an element a transition name that isn’t none, it acts as if opacity is not 1
<fantasai> s/Topic:/Subtopic:/
<fantasai> s/Topic:/Subtopic:/
<fantasai> i/Subtopic: [css-view-transitions-1] Capturing/Topic: View Transitions
<RRSAgent> I have made the request to generate https://www.w3.org/2023/03/15-css-minutes.html fantasai
<emeyer> …Name is only checked during transition, but because the new view is live, we need to check constraints per frame
<emeyer> …If constraints are not satisfied mid-transition, element is dropped from the rest of the transition
<emeyer> …If an element isn’t rendered during setup, it’s ignored
<emeyer> …If an element becomes fragmented during transition, it’s dropped
<emeyer> …How do we check these conditions?
<emeyer> …Option 1: we assert extra conditions, then check to see if the view transition name is not none
<emeyer> …If a name ever becomes none, element is dropped
<emeyer> Option 2: We assert these all individually, regardless of name
<flackr> q+
<astearns> ack flackr
<emeyer> flackr: Option 3, if an element is undergoing view transition, it is subject to the constraints
<khush> I'd be ok with that.
<emeyer> JakeA: We can’t enforce rendering and we wouldn’t enforce fragmenting
<vmpstr> +1
<emeyer> flackr: Right, we could continue to enforce name-based constraints
<astearns> ack fantasai
<emeyer> TabAtkins: My preference as well
<emeyer> fantasai: That makes sense; other thought I had was if the name changes at all, I wouldn’t be surprised if the transition is suddenly dropped
<emeyer> JakeA: We avoided that because it means we can’t deal with elements that suddenly gain a transition name
<emeyer> fantasai: I’m not saying you’d start a new transition, I’m saying if someone messes with names, it should be dropped
<emeyer> JakeA: If a paragraph isn’t in a transition and halfway through JS gives it a name, should it be ignored?
<emeyer> …If we deal with every element changed names, then you have to check every frame
<emeyer> astearns: It sounds like Option 2, except names are kept throughout the transition and so need to be checked?
<emeyer> JakeA: I think people like flackr’s option
<emeyer> …I’m happy with that
<khush> +1
<emeyer> fantasai: Wouldn’t you also be enforcing that it’s not fragmented?
<emeyer> JakeA: We would skip the transition in that case
<emeyer> fantasai: What if a thing becomes fragmented partway through? Would you just ignore that?
<emeyer> JakeA: The new views are live and updated per frame
<emeyer> …If an element becomes not-renderable…
<emeyer> fantasai: I get it
<emeyer> astearns: Option3
<JakeA> If an element is involved in a transition, the ``view-transition-name` constraints are enforced during the transition
<JakeA> It's skipped if other constraints are broken
<JakeA> (eg rendering and now fragmenting)
<emeyer> RESOLVED: If an element is involved in a transition, the `view-transition-name` constraints are enforced during the transition
<emeyer> RESOLVED: Conditions are checked per-frame; transition is skipped if other constraints are broken

[khushalsagar]

Fixed by #8540