[css-view-transitions-1] Clarify rendering constraints for elements participating in a transition

[jakearchibald]

Right now, if an element is to be captured for a view transition, we require the developer to set either layout or paint containment. There's no longer a technical reason for this, but it may still catch some unexpected behaviour.

For example, take this sidebar.

.sidebar {
  view-transition-name: sidebar;
  position: absolute;
  inset: 0 auto 0 0;
}

Imagine, due to some hacky layout, a logo overlay was within the sidebar:

.sidebar > .logo {
  position: fixed;
  right: 0;
  top: 0;
}

In CSS terms, the sidebar and the logo are independently positioned, since the logos containing block is some ancestor of the sidebar.

However, with view transitions, if we create a transition where the sidebar moves horizontally, we'll also be moving the logo, since it's part of the same capture. If the sidebar transitions to left by 100px, the old view of the logo (as part of the sidebar view) will slide to the left by 100px and fade out, and the new view of the logo will slide in from the right by 100px and fade in.

contain: layout ensures children of the sidebar will not use a parent as a containing block. It won't 'fix' the issue above, but it will make it obvious that it won't work, before the transition starts.

My thoughts on this:

• Helping developers identify issues early is good. But how common is the above gotcha?
• Even as someone involved in the spec, I frequently forget to add contain: paint and my transition fails. I then roll my eyes & add contain: paint. This might be a net negative on developer experience.
• Adding contain: paint has never saved me from the gotcha above, but my demos have been simple, so they're unlikely to have weird layouts like above.
• Removing the contain: paint requirement is a backwards compatible change, so we can do it later.

[vmpstr]

If removed, we would also have to explain in the view transition spec what happens. Since the snapshot capture would produce an atomic image, the positioned elements would be positioned initially with its real containing block, but then they will move with the pseudo element, which isn't what "normal" animations would do.

[fantasai]

I would lean towards not requiring contain. It's not really helping the developer to require it: if there's something that doesn't get captured as they expect, then they can fix that. But requiring it really makes view transitions unnecessarily complicated to use.

And more importantly, requiring it invites errors in the form of accidentally overwriting contain: somethingelse when you add a view transition because you added contain: paint.

[jakearchibald]

@fantasai does this need to be aired in a CSSWG meeting? (assuming consensus here is to remove the contain requirement)

[khushalsagar]

+1 from me as well to remove the contain requirement. But one side effect of contain: layout (or paint) is that the element becomes a stacking context. And we do need this to capture the element as an atomic image.

The spec could say that if an element has a non-none computed value for view-transition-name then it becomes a stacking context but I want to avoid unexpected side-effects from applying this property. Especially if a developer adds this property only for the duration of the transition and the layout changes in unexpected ways.

So could we require that developers explicitly ensure that named elements create a stacking context? It could be from an effect (like opacity) or by adding isolation: isolate to the element.

[vmpstr]

To add to this, I think elements participating in a view transition should have trasform-style: flat, because we will be moving the paint of this element elsewhere so it makes sense to flatten it, not to mention that this also avoids a large implementation complexity.

both opacity < 1 and isolation: isolate are grouping property values so this would work.

I want to consider that view-transition-name should imply one of the grouping properties, like isolation: isolate, without the need for there to be an ongoing transition. IOW, the presence of the property should be enough to put isolation: isolate on it to ensure that the effect imposed by the property is not ephemeral.

As a side note, view-transition-name and in general elements participating in a view transition should have isolation: isolate on its own due to the fact that the blending of captured pixels would be different in a non-normal mix-blend-mode

[khushalsagar]

+1 to requiring elements participating in a transition to have transform-style: flat. My read on the discussion so far is that there is agreement to require isolation, as described by isolation: isolate, but we don't need layout containment.

I don't have a strong preference on whether isolation should be implicitly applied based on view-transition-name or explicitly require developers to add it. I'm in agreement though that if its implicit, it shouldn't be limited to the duration of the transition. Summarizing the 2 options:

1. If an element has a non-none computed value for view-transition-name, then isolation computes to isolate. Less annoying for developers to have to add it but the side-effect on isolation could be unexpected. At least it'll be easily observable to devs since the change will be in computed value (not used).
2. If an element has a non-none computed value for view-transition-name, the author must ensure it also has isolation for the duration of ViewTransition. Failing to do so causes the transition to abort. This is the pattern being used for layout containment currently.

@fantasai @tabatkins do you have a suggestion on which pattern is better based on best CSS practices.

[vmpstr]

Layout containment aside, I'm still not convinced that we don't want the shared element to be a containing block for positioned descendants. As Jake described it initially, the effect you would get looks strange. Although I agree that the case may be rare, I think having the shared element be a containing block up front seems better and more helpful to help the developer fix their page

[khushalsagar]

The case Jake described is the reason I'm advocating against forcing the shared element to be a containing block for positioned descendants. For the layout issue mentioned in the first comment, where the nested element moves with the shared element as a part of its snapshot, developers can easily workaround this by making the descendant a shared element.

Here is a concrete example (needs Chrome running with ViewTransition enabled) which simulates what will happen if the ancestor shared element is not a containing block for a fixed position descendant:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>JS Bin</title>
</head>
  <style>
    .inner {
      position: absolute;
      width: 100px;
      height: 100px;
      background: blue;
    }
    
    .outer {
      position: fixed;
      width: 200px;
      height: 200px;
      background: red;
      view-transition-name: foo;
      contain: layout;
    }
    
    .outer_old {
      top: 0px;
      left: 0px;
    }
    .outer_new {
      top: 50px;
      left: 50px;
    }
    
    .inner_old {
      top: 10px;
      left: 10px;
    }
    .inner_new {
      top: -40px;
      left: -40px;
    }
    
    button {
      position: fixed;
      top: 250px;
    }
  </style>
  <script>
    function doTransition() {
      document.startViewTransition(() => {
        outer.classList.toggle("outer_old");
        outer.classList.toggle("outer_new");
        
        // Change position to simulate pos: fixed.
        inner.classList.toggle("inner_old");
        inner.classList.toggle("inner_new");
      });
    }
  </script>
<body>
<div class="outer outer_old" id="outer">
  <div class="inner inner_old" id="inner"></div>
</div>
<button onclick="doTransition()">Animate</>
</body>
</html>

The start/end viewport positions of inner will be based on its containing block in author DOM, which is the ICB. The animation definitely looks awkward because of the way inner fades out and then fades in at the same location. But if inner is also made a shared element, there is no issue.

On the other hand if we force shared elements to become containing blocks, authors will have no choice but to change the DOM topology if there are positioned descendants. This can be fairly complicated. Also want to point that this is not a theoretical case, we have seen partner use-cases like this.

[jakearchibald]

I'm not against view-transition-name causing an element to become a stacking context. I think developers are pretty used to that given the number of other properties that result in the same behaviour.

@khushalsagar

1. If an element has a non-none computed value for view-transition-name, then isolation computed to isolate.

I don't know if you meant this literally, but I don't think it should work literally like this. That isn't how it works with opacity etc https://jsbin.com/xuyekeh/edit?css,js,console,output

@vmpstr

To add to this, I think elements participating in a view transition should have trasform-style: flat

I don't fully get the reasons for this, but I don't mind that being a restriction. It's something we can revisit later if needed.

[khushalsagar]

Summarizing an offline discussion. TLDR, no opposition to the following requirements on a shared element:

• Must force a stacking context.
• Must flatten all descendants into the coordinate space of the shared element. Or make view-transition-name a grouping property.

Both can be done with the proposal above to use isolation: isolate for these elements.

But with respect to whether the shared element needs to be a containing block, there's good points for both options:

• Force it to be a containing block for all positioned descendants.

  • This means all descendants transform with the shared element, which is what will happen when the descendants move as a part of the snapshot anyway (unless they are also shared elements).
  • Also avoids surprised where an element's snapshot is expanded significantly because a pos: fixed descendant is far off in the shared element's layout overflow.
  • Follows the pattern of transform which forces a containing block.

• Don't force it to be a containing block. You get the weird animation in the comment above, but:

  • Developers can fix it trivially by making the descendant a shared element.
  • They can also explicitly force the shared element to be a containing block (with contain: layout or transform: translate: 0px) if that's the desired behaviour. Instead of the browser forcing this behaviour that the developer can not change.

This needs more input from developers.

[jakearchibald]

Both can be done with the proposal above to use isolation: isolate for these elements.

This won't literally use isolation: isolate in any observable way. It will just create a stacking context in the same way opacity does for values less than 1 (and yes, in the same way isolation: isolate does).

But with respect to whether the shared element needs to be a containing block, there's good points for both options:

I like features that have a default that prevents common errors, especially if that error isn't immediately obvious.

But in this case any error will be immediately obvious. And, I think there will be cases where the developer really doesn't want a containing block here.

[khushalsagar]

This won't literally use isolation: isolate in any observable way.

Depends on how we want to spec it:

1. A non-none computed value of view-transition-name causes the element to generate a stacking context and is a grouping property value.
2. A non-none computed value of view-transition-name causes the element's used value for isolation to be isolate. If the change is in computed value of isolation, instead of used, then it will be observable to developers.

Since isolation already conceptually maps to what we want, could build on that concept.

I think there will be cases where the developer really doesn't want a containing block here.

+1. That's why I'm leaning towards no containing block by default, with guidance on how developers can detect and fix common errors (by manually adding contain: layout for example).

[jakearchibald]

Depends on how we want to spec it:

I vote for 1, since that's how the other grouping properties behave. Or is this behaving differently to other grouping properties?

[ydaniv]

From this:

Summarizing an offline discussion. TLDR, no opposition to the following requirements on a shared element:

• Must force a stacking context.
• Must flatten all descendants into the coordinate space of the shared element. Or make view-transition-name a grouping property.

Follows that view-transition-name should be a grouping property, then, AFAICT looks like 1 it is.

[ydaniv]

Damn, we just hit that after several hours of debugging 🙈
So another +1 to @fantasai's suggestion.

[khushalsagar]

Sorry @ydaniv, this is getting fixed soon. :)

I missed another restriction we need, the named element needs to be the backdrop root for descendants with a backdrop filter. Given that this element's painting will be rendered via the pseudo-element, it doesn't make sense for an ancestor to readback the named element's painting. @mfreed7 FYI.

So the constraints required on a named element, implicitly applied if it has a non-none computed value for view-transition-name, are:

• Generate a stacking context.
• Be a grouping property.
• Be the backdrop filter root for all descendants.

Still undecided on whether it needs to be a containing block.

[jakearchibald]

One decision remaining on this, is how we should handle:

• named-element has a view-transition-name
• child, is a child of named-element, is fix-pos, and uses a containing block that's an ancestor of named-element

Source

<style>
  .named-element,
  .child {
    width: 150px;
    height: 150px;
    background: green;
  }

  .named-element {
    view-transition-name: named-element;
    margin: 120px;
  }
  
  .child {
    background: blue;
    position: fixed;
    top: 0;
    left: 0;
  }
</style>
<div class="named-element">
  named-element
  <div class="child">child</div>
</div>

Which looks like this:

How should the view-transition work, considering changes to named-element, such as position and background color?

Option 1: Capture as-is

Capture named-element and all its content. The size of the image is the border box of named-element.

Here's how the background color and position transitions would look:

out.mp4

The background color animation looks good. However, the position transition doesn't look 'right', since the captures move with the bounding box of named-element, yet the child has remained fixed.

If this isn't what the developer wants, they can make the child part of the transition too:

.child {
  view-transition-name: child;
}

And the result:

out.mp4

Option 2: Exclude the child from the capture

named-element is captured excluding the child, because it uses a containing block that's an ancestor of named-element. The child is instead captured with the view-transition part that's closest (as in el.closest()) to the child's containing block, which is the root in this case.

Here's how that would look:

out.mp4

This doesn't look quite right, as the named-element appears over the child during the transition, since the child is now painted onto the root.

The fix is the same as before, which is to make the child part of the transition.

This option seems similar to how Firefox handled element() https://jsbin.com/puwofoviqa/edit?html,css,output

Option 3: Force a containing block

Adding a non-none view-transition-name to an element causes it to be a containing block, similar to transforms and filters.

When the developer does this, their layout will break before they even get to the transition, which should be easy to spot.

The best fix for this would be for the developer to change the DOM so the fix-pos element is no longer within named-element.

This is already the case if the developer wants to animate a transform.

[flackr]

Note regarding option 3, we may be able to say that view-transition-name is only a forced container for elements which do not also have a view-transition-name, allowing the same ability for developers to keep them separate the same way as the first two.

[khushalsagar]

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 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). @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.

[jakearchibald]

I really want to keep this simple rule for developers: When a view transition happens, for each element with a view-transition-name, it, and its descendants, are captured separately as an image.

Given that, I'm not convinced that option 1 breaks developer expectations. Or, if it isn't initially what they expect, a quick look at the old and new images should make it clear.

Even with forcing a containment block, you can achieve the same effect by counter-transforming the child element (it's how the demo was made). It looks weird, sure, but it's following the rule of capturing the element as an image, which seems easy to understand.

Option 2 is a smart workaround, but it breaks the simple rule. The rule becomes: When a view transition happens, for each element with a view-transition-name, it, and its descendants that use a containing block that is not an ancestor of element, are captured separately as an image. Remaining elements are left for parent captures.

I think that's much harder to understand, and will lead to more unexpected behaviour. Also, when developers encounter this unexpected behaviour, I don't think they're going to easily figure out what's happening.

Option 3 maintains the simple rule, but adds an additional rule: view-transition-name causes a containing block. Although, this is a rule that also comes with setting transforms, so maybe it isn't a big deal. I don't like that it forces the developer to change their DOM.

Option 4 builds on option 3 by giving you a way to workaround the issue without changing DOM, but it seems like a new bit of layout 'magic' to learn.

My preference is option 1. It does what it says, without introducing new rules to learn. If it creates an effect the developer doesn't want, it's easy to figure out and resolve.

[mirisuzanne]

I agree with @jakearchibald on this – I'd vote for option 1. When option 1 'fails' (by not providing a perfect default transition) - that failure is clear to see, understand, and address without any changes to the DOM or other aspects of the layout. The solution is contained to the view-transition. The other options try to magically enforce a perfect default, but end up introducing less obvious side-effects.

[jakearchibald]

Summary for the CSSWG meeting:

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

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

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

.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 an opacity less than 1 gain a bunch of behaviours, such as stacking context, without that being set explicitly. What those behaviours are is the next resolution.

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.

In cases like this, the size and position of the group is still the border-box of the element with the view-transition-name, and the fixed-pos element is ink overflow.

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

out.mp4

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

We considered forcing a containing block to prevent this effect (similar to setting a transform on an element), 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 has 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.

[flackr]

Given that opacity has established that we can paint the content independently without containment, I think technically option 1 should work.

My main concern is that non-contained descendants will result in the capture being much larger than the developer realizes (e.g. bounding box of the capture element to the current position of the descendants), however perhaps #8282 will help with this and make it less of an issue.

I was also concerned that the inconsistency between this behavior (which effectively allows animating transform without containment) where normally any non-none transform forces containment would be confusing for developers. I can understand how forcing containment can be surprising to developers, but it is the way that transforms work which developers already likely have to deal with. I'm not sure what lead to transforms doing this, and if that rationale is applicable here. Perhaps opacity behaving differently is a good reason we don't need this.

[khushalsagar]

I was also concerned that the inconsistency between this behavior (which effectively allows animating transform without containment) where normally any non-none transform forces containment would be confusing for developers. I can understand how forcing containment can be surprising to developers, but it is the way that transforms work which developers already likely have to deal with. I'm not sure what lead to transforms doing this, and if that rationale is applicable here. Perhaps opacity behaving differently is a good reason we don't need this.

#913 has history behind why transforms force a containing block. The short answer is implementation complexity across all engines, effects like filter cause the same. A lot of developers have expressed frustration with this decision on the issue. That tells me that if browsers can support this, most developers would prefer option 1. From Blink's perspective, implementation complexity is not a concern because opacity establishes a similar pattern.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] Clarify rendering constraints for elements participating in a transition, and agreed to the following:

• RESOLVED: Remove contain:layout requirement for view-transition to work
• RESOLVED: A non-none view-transition-name acts similar to a non-1 opacity (stacking context, grouping element, backdrop root)

The full IRC log of that discussion

<JakeA> https://github.com//issues/8139#issuecomment-1422602510
<TabAtkins> JakeA: I linked to an overview
<TabAtkins> JakeA: trying to roll two resolutions into one, very related
<chris> thanks fantasai
<emilio> persent+
<TabAtkins> JakeA: when we first did an experimental impl, we required paint containment on anything that was gonna be a view transition group
<TabAtkins> JakeA: we improved our impl and no longer needed that
<TabAtkins> JakeA: We're still asking for contain:layout to make it a containing block, tho
<TabAtkins> JakeA: This is a bad dev exp
<TabAtkins> JakeA: The transition fails, dunno what's going on, have to look in devtools for it
<TabAtkins> JakeA: We've heard from devs they hit the smae issues
<TabAtkins> JakeA: So first proposed resolution is we remove the contain:layout requirement, and instead we auto-apply those containments to elements with a view-transition name
<florian> q+
<TabAtkins> JakeA: This is similar to how opacity triggers a stackign context, etc
<argyle> yay, remove it! JIT contain
<astearns> ack florian
<TabAtkins> florian: So when you turn things on, you're not modifying 'contain' computed value, but turning them on *as if* contain was set appropriately?
<TabAtkins> JakeA: Yeah, doing same as opacity
<TabAtkins> florian: sounds reasonable
<TabAtkins> florian: I think content-visibility also turns on some containment without messing with computed value
<miriam> `container-type` does the same
<dbaron> Agree that it should be consistent with content-visibility... which I think this is.
<TabAtkins> +1
<argyle> +1
<TabAtkins> fantasai: Are you planning to auto-apply layout containment?
<TabAtkins> JakeA: That's the second part of the issue
<TabAtkins> PROPOSED RESOLUTION: Remove contain:layout requirement from view transitions
<TabAtkins> TabAtkins: This is an incomplete reoslution - we're just changing it from "author must specify" to "we automatically add containment"
<TabAtkins> RESOLVED: Remove contain:layout requirement for view-transition to work
<TabAtkins> JakeA: So adding view-transition makes the element a stackign content, a backing root, etc. Same as opacity.
<TabAtkins> JakeA: Shoudl it also become a containing block?
<TabAtkins> JakeA: So what should happen to elements inside the transitioning element that use a containing block outside? We've seen examples of fixpos.
<fantasai> s/stackign content, a backing root, etc./generate a stacking context, be agrouping property (forces flat preserve-3d), and be a backdrop root/
<TabAtkins> JakeA: If the beahvior is that we capture the texture as-is (the fixpos is contained in that capture) and we do a transition where the element moves without hte fixpos moving with it
<TabAtkins> JakeA: it can look odd - the fixpos is now in a different relative position, but the texture hasn't been updated
<TabAtkins> JakeA: There's a video in the issue if my description is confusing
<TabAtkins> JakeA: We considered forcing a containing block to prevent that effect
<TabAtkins> JakeA: That requires the dev to move the fixpos out of the captured element
<TabAtkins> JakeA: Also considered more complex to exclude the fixpos from the capture
<TabAtkins> JakeA: Instead capturing it with their containing block
<TabAtkins> JakeA: Our conclusion is tha tforcing a CB requires the author to change their DOM, which seems bad, and we have real-world cases that hit this
<TabAtkins> JakeA: We also want to keep a simple rule that an element with a view-transition captures the element and its descendants. Not capturing fixposes breaks that.
<TabAtkins> JakeA: If we don't fix this tho, we get animations that the author clearly didn't intend
<TabAtkins> JakeA: The easiest fix seems to be to give the fixpos a view-transition name, so it view-transitions on its own
<emilio> q+
<astearns> ack emilio
<TabAtkins> JakeA: So our proposal is that view-transitions *do not* force a containing block
<TabAtkins> emilio: What's the plan for animating transform on the image?
<fantasai> summary comment is https://github.com//issues/8139#issuecomment-1422602510 btw
<TabAtkins> emilio: That seems like it adds complications vs creating a fixpos CB
<TabAtkins> JakeA: If animating a transform on the old or new view, you're moving the texture around as a group - you can see it in the video in the issue
<TabAtkins> emilio: You need to define the bounds that somehow encloses the abspos and fixpos, otherwise what you're animating is not... i think it introduces complications
<TabAtkins> JakeA: The demo I posted in the issue, I created that by having an abspos that starts outside the border of the VT element. We don't do paint containment anymore, so that's fine. You already have to calculate the size and positions from the VT elements, even i there's ink overflow (shadows, filters, or things like positioned descendants)
<TabAtkins> emilio: So the transform box is the element, and everything that escapes is just overflow.
<TabAtkins> emilio: So if you set trasnform-origin, what are those %s relative to?
<TabAtkins> JakeA: If you're setting trasnform-origin on the ::view-* pseudos, it's relative to the border box of that element.
<TabAtkins> JakeA: We allow repalced content to overflow (ink overflow).
<TabAtkins> emilio: Right, but ink overflow here includes abspos element that used to overflow the transitioning element
<TabAtkins> JakeA: That's true today, right?
<TabAtkins> emilio: The box relationship is different when you have fixpos inside a transform vs not
<khush> q+
<TabAtkins> emilio: So it might be weird if it takes the same trasnform origin
<TabAtkins> emilio: But maybe it's okay for the transition..
<TabAtkins> (I still don't understand the issue being discussed.)
<astearns> ack khush
<TabAtkins> khush: Impl-wise, we use a very similar path to opacity.
<TabAtkins> khush: Say the element has to be painted atomically. For elements tha toverflow you find out where they are relative to the VT element, and just use object-overflwo. The layout overflow of the element becomes ink overflow of the transition pseudo.
<TabAtkins> emilio: Okay that answers my question
<TabAtkins> JakeA: So proposed resolution is view-transition does not create a containing block for the element
<TabAtkins> astearns: Proposed resolution is that view-transition makes the element a stacking context, a grouping element, and a backdrop root
<TabAtkins> smfr: This applies at all times, not just while the transition is running, right?
<TabAtkins> JakeA: Yes, we think that's more consistent.
<TabAtkins> smfr: I think a note in the spec about the fixpos behavior would be useful.
<TabAtkins> TabAtkins: Are these effects different from contain:layout?
<TabAtkins> JakeA: Yes, layout contianment causes a CB as well.
<TabAtkins> flackr: I have a concern that this can make it easy for devs to make large cpatured elements, but there's another issue about that and shoudln't block this
<TabAtkins> flackr: Also this is different from transform, and I just wanted to make sure there weren't transform-relevant reasons to make it similar, but khushal's response answers that
<TabAtkins> astearns: Objections?
<TabAtkins> RESOLVED: A non-none view-transition-name acts similar to a non-1 opacity (stacking context, grouping element, backdrop root)
<fantasai> scribenick: fantasai

[jakearchibald]

@fantasai @tabatkins I need a bit of advice for speccing this. It seems like there isn't consistency when it comes to where to define this. The choices are:

• Option 1: Along with the view-transition-name definition (eg "using this makes the element a stacking context")
• Option 2: Along with the layout concept (eg "the following properties are grouping property values… view-transition-name)

Taking opacity as an example:

• Stacking context: option 1
• Grouping element: option 2
• Backdrop root: option 2

Should I just do the same as opacity here, and do both options depending on the effect? In cases I do option 2, I'll add a note to the view transitions spec.

[jakearchibald]

I'm going to go for option 1 for all three. It can be changed later if needed.