Re: [csswg-drafts] [css-view-transitions-1] Clarify rendering constraints for elements participating in a transition (#8139)

Summary for the CSSWG meeting:

In our early implementation, paint containment was required for captured elements.

```css
.header {
  view-transition-name: header;
  contain: paint;
}
```

This requirement was lifted, but we still required layout containment, to ensure captured elements were containing blocks.

```css
.header {
  view-transition-name: header;
  contain: layout;
}
```

This turned out to be frustrating, because it was easy to forget about, the transition would fail, you'd see the warning in dev tools, then add `contain: layout`. It felt like this happened every time. I experienced this myself, and heard the same from other developers.

Resolution 1 of 2: Remove the requirement to set `contain: layout`, and instead apply any requirements to elements that have a `view-transition-name`. Similar to how elements with a `transform` become containing blocks, without that being set explicitly.

Assuming resolution 1 is passed, a non-`none` `view-transition-name` will cause the element to:

- generate a stacking context
- be a grouping property (forces flat preserve-3d)
- be a backdrop root

…which is the same set of behaviours that comes with `opacity` less than 1.

The remaining question is: how should we handle elements within the captured element, that use a containing block that's outside the element? We've seen this in the wild, with one of our partners testing the API - they had a pos-fixed close button inside an element with a `view-transition-name`.

If the element moves position (and the pos-fixed element naturally doesn't), you can end up with a transition which looks like this:

https://user-images.githubusercontent.com/93594/214614069-f1f6e456-9914-4aff-93de-a0bc8e154094.mp4

…where the pos-fixed element moves when it shouldn't.

We considered forcing a containing block to prevent this effect, requiring the developer to move the fixed-pos element out of the captured element if they want the same layout.

We also considered more complex solutions that allowed for the fix-pos element to be excluded from the capture, and instead be captured along with the group associated with its containing block.

However, we concluded that:

- Forcing a containing block requires the developer to alter their DOM, which feels like it will hurt adoption - again we've seen this in real-world cases.
- We'd like to keep a simple rule: When an element as a `view-transition-name`, it, and its descendants, are captured separately as an image. The more complex solutions we thought of break that rule.
- Cases where this results in an animation the developer didn't expect are clear to see, understand, and address without any changes to the DOM or other aspects of the layout (thanks @mirisuzanne for that summary). The fix is usually to give the fix-pos element its own `view-transition-name`.

So resolution 2 of 2: Don't require or force a containing block. Capture the element and all its descendants as-is, even if they're positioned to a parent containing block.

-- 
GitHub Notification of comment by jakearchibald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8139#issuecomment-1422602510 using your GitHub account


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

Received on Wednesday, 8 February 2023 13:29:09 UTC