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

Thanks for the excellent summary @jakearchibald and @flackr for thinking through the options. We've been weighing these options against 3 parameters: developer expectations (does the behaviour during the transition align with what developers would expect given a layout), developer ease of use (how easy is to for developers to get the behaviour they want, if the default doesn't work for them) and ease of implementation for the engine.

Here's my take for the 3 options:

- Option 1
   - Developer expectation: Doesn't line up with developer expectations since child is not positioned relative to its containing block during the transition. But works for any case where the named ancestor doesn't have a position animation.
   - Developer ease of use: Can make the child a named element to move it independently. Some desired behaviour can not be achieved, for example in the case where where a node between the named element and child has opacity. The opacity won't apply since named elements don't get ancestor effects in their snapshots.
   [Nested transition groups](https://github.com/WICG/view-transitions/blob/main/explainer.md#nested-transition-groups) will eventually fix this.
   
   - Implementation Complexity: Easy to implement (speaking from Blink's perspective). Since `opacity` forces a stacking context but not a containing block, there is precedent to paint a DOM element as an atomic unit with descendants that don't use this DOM element as a containing block.
   We did notice that element() in Gecko skips fixed positioned descendants so maybe there is implementation complexity there ([demo](https://jsbin.com/nuwukob/edit?html,css,output)). @emilio @dholbert for feedback.
   
- Option 2
   - Developer expectation: Doesn't line up with developer expectations since child paints into a different stacking context than it normally would. 
      This means the child wouldn't have effects like opacity from an ancestor which is between the named element and child in the hierarchy. But this is already possible if the child is a named element, since its snapshot excludes ancestor effects by design.
      The paint order would also change (as shown in the example). But this is also already possible. If there are 3 sibling elements with a paint order of a, b, c and b becomes a named element, then a and c get squashed into their ancestor's snapshot while b draws on top (as an independent snapshot).
   - Developer ease of use: Same as option 1.
   - Implementation Complexity: Harder to implement than option 1. There isn't an existing pattern to change the stacking context hierarchy this way.

- Option 3
   - Developer expectation: Lines up with developer expectations, child moves with the named ancestor since its forced to be its containing block.
   - Developer ease of use: Must change the DOM topology if there is a child which shouldn't use a named ancestor as its containing block.
   - Implementation Complexity: None. Its a subset of the constraints that come with layout containment.

- Option 4
   This is from flackr's last comment, the named element is a containing block for all descendants except other named elements.
  - Developer expectation: Unsure. It would be a new pattern for developers to learn, since view-transition-name can now selectively change the containing block for some elements.
  - Developer ease of use: Similar to option 1/2. The downside I see is that developers could be forced to make a child a named element even if its not needed, for example in the background color animation case in Jake's summary of option 1. Each named element has a memory cost to be rendered into an independent snapshot.
  - Implementation Complexity: Minimal.

My preference order would be option 1 followed by option 4. Option 2 trades one set of unexpected behaviour from option 1 with a different set of unexpected behaviour and adds implementation complexity. Option 3 seems too restrictive for developers. I'd err on the option which is better for developer expectation/ease of use so would help to hear developer feedback on this. @mirisuzanne FYI.

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


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

Received on Wednesday, 25 January 2023 18:05:41 UTC