[css-view-transitions-2] Proposal for a view-transition-tree property (name tbd)

[vmpstr]

View transitions right now construct a tree of pseudo elements that in some sense "flattened". That is, each ::view-transition-group is a direct child of ::view-transition, which is a pseudo child of :root. This allows some nice effects where each piece of a transition moves independently.

However, there is also desire to have some relationship between the constructed groups.

1. Some elements should move relative to their containers while their containers are also participating in a transition. This could be something like a box moving across the screen and the contents within that box also animate in an orthogonal axis.
2. Some elements want to be clipped by the ancestor that is also participating in a transition. For example a button that stays the same size but its contents expand within the clip and crossfade.

Essentially what we want is for some elements to maintain their hierarchical relationship, where a ::view-transition-group can have another ::view-transition-group as a child.

The proposal is to add a new view-transition-tree property that takes two values: flatten and preserve. This property would only have an effect if a view-transition-name is also specified.

The flatten value would be the default value and act as it acts today, the element on which this appears does not affect how the view transition descendants are constructed.

The preserve value would act as a sort of a "containing block" for the view transition descendants: all of the descendants would be nested under their nearest preserve ancestor.

All of the names are bikesheddable, of course

/cc @nt1m @khushalsagar @noamr @jakearchibald

[jakearchibald]

Thinking through an example:

ScreenFlow.mp4

In this case, the top box doesn't want to be contained, as it wants to transition between containers, whereas the other items need to be contained within the container.

I can think of a couple of ways of doing this:

Option 1: Manual grouping

view-transition-parent: name | auto | none. Takes the name of a group to be nested within, or auto, which takes the name of the closest ancestor with a view-transition-name.

So, for the above example:

<div class="container-1">
  <div class="card card-switching-containers" style="view-transition-name: card-1"></div>
  <div class="card" style="view-transition-name: card-2"></div>
  <div class="card" style="view-transition-name: card-3"></div>
  <div class="card" style="view-transition-name: card-4"></div>
</div>
<div class="container-2"></div>

And the CSS for the transition:

.container-1 {
  view-transition-name: container-1;
}

.card {
  view-transition-parent: auto;
}

.card-switching-containers {
  view-transition-parent: none;
}

html::view-transition-group(container-1) {
  overflow: clip;
}

This is a bit manual, as I need to set things up for this particular transition.

Option 2: Auto grouping

The view-transition-tree proposal in the OP, but children are grouped to the closest view-transition-tree: preserve 'parent' that is in both the old and new states.

<div class="container-1">
  <div class="card" style="view-transition-name: card-1"></div>
  <div class="card" style="view-transition-name: card-2"></div>
  <div class="card" style="view-transition-name: card-3"></div>
  <div class="card" style="view-transition-name: card-4"></div>
</div>
<div class="container-2"></div>

And the CSS for the transition:

.container-1 {
  view-transition-name: container-1;
  view-transition-tree: preserve;
}

html::view-transition-group(container-1) {
  overflow: clip;
}

This case 'just works', because a given card won't be grouped within container-1's group if it's moving to/from container-2.

I wonder if there are cases this doesn't provide enough flexibility.

If the tree goes from three groups A > B > C to B > A > C, which group would C be part of?

Option 3: both?

Allow option 2, but also allow individual children to assign themselves to a particular parent group. The assignment from the child would take priority.

[nt1m]

With view-transition-tree: preserve | flatten it's unclear to me whether what container to apply it on, or even if it applies to the container or the child in the first place.

view-transition-parent: <name> | auto | none is better in terms of use-case coverage, but the main issue is circularity (.child { view-transition-parent: parent; } .parent { view-transition-parent: child }), it would be good to avoid this footgun.

I don't have great suggestions on top of my head, but could the use cases be covered by scoped element transitions? e.g. making so running a document VT + a scoped element transition concurrently parents things accordingly? or having some API to run both at the same time?

[jakearchibald]

The circularity is a good point. Option 2 doesn't have that problem.

I don't have great suggestions on top of my head, but could the use cases be covered by scoped element transitions? e.g. making so running a document VT + a scoped element transition concurrently parents things accordingly? or having some API to run both at the same time?

Interesting! But don't we run into all sorts of problems by trying to run two nested transitions like this?

[vmpstr]

I agree that the circularity is a problem that needs to be solved for option 1 (which is why I haven't mentioned it, but did think about it).

Auto grouping makes the example above awkward to express, since you need to modify your dom to encompass some things but not others.

I like option 3, just have both: by default view-transition-tree establishes a grouping for descendant vt elements -- this solves a lot of cases without needing to specify parents on each descendant -- and have the ability to explicitly name an ancestor with view-transition-parent. Note that the circularity is resolved in that the named parent has to be an ancestor of this element, otherwise the name is invalid

[khushalsagar]

In this case, the top box doesn't want to be contained, as it wants to transition between containers, whereas the other items need to be contained within the container.

That's an excellent point Jake. We actually considered option 1 too but leaned towards option 2 because it avoids the possibility of circularity. The use-case you mentioned though is a good reason to go for option 1. We already know which names appear in the ancestor chain when we reach a named element, so its trivial to fix the circularity issue by simply ignoring the view-transition-parent not in the chain.

If we have to pick an option, the view-transition-parent one is maximally flexible. option 1 is then syntactic sugar for a common use-case.

Re: mismatch in old and new DOM hierarchy, the situation can happen with either syntax option. We can consider a couple of options:

1. The ancestor is decided based on the old DOM. So if a name appears in the old DOM, we ignore the view-transition-parent for it specified in the new DOM. This is similar to our approach for paint order, we let the paint order of names be decided by the old DOM. It's only for entry animations that we consider parent declarations in the new DOM.
2. If the ancestor mismatches for an element between old and new DOM, then fallback to flattening to the root.

I don't have great suggestions on top of my head, but could the use cases be covered by scoped element transitions? e.g. making so running a document VT + a scoped element transition concurrently parents things accordingly? or having some API to run both at the same time?

Excellent question! The use-cases we've seen do involve a full page transition. Think clicking on a button which expands to a widget while the background changes. This kind of thing is harder to coordinate with 2 independent transitions. We also have to think through how to deal with resizing for scoped transitions. For the scoped element, its layout for the end state will keep changing as its resized.

That said, @jakearchibald's example of a subset of nested elements being clipped can't be solved with scoped transitions. When a scoped transition is started, only elements in the subtree of the scoping element can participate in that transition. Content inside the scoping element can't animate out of it. For this you do need a transition at the root but with nested ::view-transition-groups.

[vmpstr]

• The ancestor is decided based on the old DOM. So if a name appears in the old DOM, we ignore the view-transition-parent for it specified in the new DOM. This is similar to our approach for paint order, we let the paint order of names be decided by the old DOM. It's only for entry animations that we consider parent declarations in the new DOM.
• If the ancestor mismatches for an element between old and new DOM, then fallback to flattening to the root.

FWIW, I prefer keeping the old dom structure. So in exit or paired animations, the old state determines the structure. For entry animations, the new state determines where to attach the entry groups. It's simple and I suspect most of the time works for reasonable effects

[khushalsagar]

FWIW, I prefer keeping the old dom structure. So in exit or paired animations, the old state determines the structure.

SGTM! @jakearchibald @nt1m do you see any issues with this approach?

[jakearchibald]

@khushalsagar

If we have to pick 1, seems like option 2 is maximally flexible. option 1 is then syntactic sugar for a common use-case.

The other way around, no?

[jakearchibald]

@khushalsagar @vmpstr

FWIW, I prefer keeping the old dom structure.

I don't think I fully understand what's being proposed here.

In this example:

<div class="container-1">
  <div class="card" style="view-transition-name: card-1"></div>
  <div class="card" style="view-transition-name: card-2"></div>
  <div class="card" style="view-transition-name: card-3"></div>
  <div class="card" style="view-transition-name: card-4"></div>
</div>
<div class="container-2"></div>

And the CSS for the transition:

.container-1 {
  view-transition-name: container-1;
  view-transition-tree: preserve;
}

html::view-transition-group(container-1) {
  overflow: clip;
}

If card-1 is moved to container-2, where will ::view-transition-group(card-1) be nested?

[vmpstr]

The proposal is to keep it in the structure where it appeared in the old state. So if both container-1 and container-2 are view-transition-tree: preserve, then the ultimate structure is something like the following:

::view-transition
|__ ::view-transition-group(root)
|__ ::view-transition-group(container-1)
|   |__ ::view-transition-group(card1)
|   |__ ::view-transition-group(card2)
|__ ::view-transition-group(container-2)

In other words, even though the card moved in the "new state", in the "old state" it's still a part of container-1.

With the clip, it means that the card will "disappear" as it tries to slide out of container-1. I realize that it precludes it sliding in, but I think that's fine since we don't want effects that make an element disappear (because of new container clipping) and then slide into view again.

[khushalsagar]

The other way around, no?

Yup. Sorry, fixed the comment above.

If card-1 is moved to container-2, where will ::view-transition-group(card-1)

What @vmpstr said. In the case above, you want card-1 to be under ::view-transition directly right? So I think this example would work with view-transition-parent + the approach to use old state parent names (if provided).

[calinoracation]

Our use case typically would benefit most from Option 1. We do have cases like @jakearchibald demonstrates in #10334 (comment) where we move an item from 1 container to another, and we want to contain the items moving to the second container that might be in a another tree. Here's an example where we move a group of items from 1 container to the other. We'd definitely use the view-transition-parent in this case:

80ec9e897c407837b4a0761ad3037299.mp4

I did have another use-case that I've been curious about, if we have the view-transition-parent set or just in general, it would be great to have access to the underlying data as well if we want to say animate a clip-path or do an offset within it. Something like clip-path: inset(env(view-transition-parent-top) ...). Having access to other ones would be great too but I realize that might be adding a lot of complexity.

[khushalsagar]

it would be great to have access to the underlying data as well

Can you expand a bit more on what you mean by "access to underlying data"? I suspect you already have the bits you need via getComputedStyle on the pseudos.

[calinoracation]

Can you expand a bit more on what you mean by "access to underlying data"? I suspect you already have the bits you need via getComputedStyle on the pseudos.

Oh, I didn't realize we could do that, yeah actually nevermind then, that's perfect. I think the primary issue with that would be say if it was access to dimensions of a parent that are animating to a new size, but that should be covered by the view-transition-parent option.

[khushalsagar]

Evaluating how view-transition-parent would work with the naming proposals on #8320.

There shouldn't be an issue with the attr() and element-uuid() syntax. One of the examples on the issue shows how custom properties allow using a parent's name on a child. For example,

.card {
  --card-id: element-uuid();
  view-transition-name: ident(var(--card-id));

  img {
    view-transition-parent: ident(var(--card-id));
    view-transition-name: ident(var(--card-id) "-img");
  }
}

But I don't see how view-transition-parent could be set if an ancestor was named via view-transition-name: auto. Not a big deal, we don't have to support all naming syntaxes with view-transition-parent. Just something worth thinking through.

[khushalsagar]

Proposed resolution to go with option 3 from the comment above: #10334 (comment).

One question, what should happen if the author adds view-transition-parent to a child but doesn't add view-transition-tree: preserve to the corresponding parent? Is view-transition-parent enough to opt-in to grouping under that parent or does that parent explicitly need to allow grouping under it via view-transition-tree.

The pro of requiring view-transition-tree is that it aligns closely with position: absolute so would make it easier for authors to understand the concept. The con is that if only child under a node wants to be parented under it, then the author explicitly has to set view-transition-parent: none for all named elements under that parent. I lean strongly towards not requiring view-transition-tree but this comes down to what would be more preferable for authors. So happy to go with either based on developer feedback.

@jakearchibald @calinoracation any suggestions?

[vmpstr]

I lean strongly towards not requiring view-transition-tree

Can you elaborate on the reasons?

Requiring view-transition-tree would indeed closer align with the containing block models found elsewhere. Typically it is the properties of an element that make it a containing block, not the fact that a descendant references it in some property. It is also somewhat strange to me that this element would only nest the referenced element, and not the rest of its descendants (unless also explicitly named). Are there any other CSS concepts that align closer to this? For some reason I'm thinking of anchor positioning, but even there, I don't think there's this type of effect

[khushalsagar]

Can you elaborate on the reasons?

It's mostly this use-case: "I have a list of cards in a container and only one of them needs to be parented to that container". Adding view-transition-parent to that one card would be the least lines of code to accomplish it. The other way, view-transition-tree on the parent + a view-transition-parent: none on all other children is more code and I don't see why that's better.

It is also somewhat strange to me that this element would only nest the referenced element, and not the rest of its descendants (unless also explicitly named).

The author can get this behaviour by using view-transition-tree though. I just think that the use-case of only child being nested under a parent is also a valid use-case and we don't have to choose a syntax which makes it unnecessarily verbose.

Are there any other CSS concepts that align closer to this? For some reason I'm thinking of anchor positioning, but even there, I don't think there's this type of effect

Good question. Anchor positioning does require a anchor-name declaration for another element to be able to anchor to it. But I suspect its because you need a way to identify that element in CSS and add constraints to it to be able to be an anchor. We're already getting all of that by the fact that the parent needs to have a view-transition-name. So we don't need to also add view-transition-tree? @tabatkins to validate my thinking.

[vmpstr]

One approach would be to make view-transition-parent an inherited property, so to accomplish the use-case in question you would do something like the following:

.container {
  view-transition-name: container;
  view-transition-tree: preserve;
  view-transition-parent: none;
}
.special-item {
  view-transition-name: special-item;
  view-transition-parent: container;
}
.other-item {
  view-transition-name: other-item;
  /* view-transition-parent: none is inherited from .container */
}

I think whether or not view-transition-parent should be inherited is a worthwhile topic on its own, since if an element wants to have a different parent, presumably all its children by default also want to have that parent? Or are there use cases where this is not true?

I guess a counter example to inheriting is also the above case where the container wants to escape its parent, but all the children should be auto. The only way to do that is something like the following:

.container {
  view-transition-name: container;
  view-transition-tree: preserve;
  view-transition-parent: none;
}
.container > * {
  view-transition-parent: auto;
}

which seems unintuitive

[khushalsagar]

One approach would be to make view-transition-parent an inherited property

We don't need it to be an inherited property for this. A simple descendant selector will do it, though it reads kinda awkward.

.container {
  view-transition-name: container;

  /* Parent all named children to me. */
  view-transition-tree: preserve;
}

.container * {
  /* Actually, don't. */
  view-transition-parent: none;
}

I think whether or not view-transition-parent should be inherited is a worthwhile topic on its own

That's true! I'm not sure about this: "since if an element wants to have a different parent, presumably all its children by default also want to have that parent?". I expect the common case would be for that element's children to be parented to it. Something like:

.container {
  /* Parent me to foo */
  view-transition-parent: foo;

  /* Parent all named children to me */
  view-transition-tree: preserve;
}

In fact since the proposal above is for view-transition-parent to have preference over view-transition-tree, in the above example inheriting view-transition-parent would mean the author has to remove it.

[bramus]

One thing I’m not entirely convinced of is the fact that the containers in the given example need to have a view-transition-name although these containers themselves don’t actually transition. Only reason to do this, is to enable clipping. Feels like a technicality that puts extra load on the author and also increases the number of captured elements.

Maybe there could be a way to mark element to become a “view transition container” that automatically clips its participating contents without the container itself moving around or stuff? I’m leaning towards CSS Containment for this.

• Example using keywords:

  • CSS:

    .container {
      container-type: view-transitions; /* Capture my dimensions and use it to clip the VT snapshots contained */
    }
    
    .card {
      view-transition-name: auto;
      view-transition-container: nearest; /* default */
    }
    
    .card-switching-containers {
      view-transition-name: the-card;
      view-transition-container: none; /* render as direct child of the ::view-transition pseudo */
    }

  • Resulting Tree:

    ::view-transition
    |__ ::view-transition-group(root)
    |__ ::view-transition-container(container-1)
    |   |__ ::view-transition-group(card1)
    |   |__ ::view-transition-group(card2)
    |__ ::view-transition-container(container-2)
    |   |__ ::view-transition-group(card3)
    |   |__ ::view-transition-group(card4)
    |__ ::view-transition-group(the-card)
    

• Example using a named container:

  • CSS:

    .container {
      container-type: view-transitions;
    }
    
    .containers-wrapper {
      container: containers-wrapper / view-transitions; /* Named container */
    }
    
    .card {
      view-transition-name: auto;
      view-transition-container: nearest; /* default */
    }
    
    .card-switching-containers {
      view-transition-name: the-card;
      view-transition-parent: containers-wrapper; /* render in the containers-wrapper pseudo */
    }

  • Resulting tree:

    ::view-transition
    |__ ::view-transition-group(root)
    |__ ::view-transition-container(container-wrapper)
        |__ ::view-transition-container(container-1)
        |   |__ ::view-transition-group(card1)
        |   |__ ::view-transition-group(card2)
        |__ ::view-transition-container(container-2)
        |   |__ ::view-transition-group(card3)
        |   |__ ::view-transition-group(card4)
        |__ ::view-transition-group(the-card)
    

Setting container-type to view-transitions basically does the view-transition-tree: preserve thing covered in this thread.

[khushalsagar]

Only reason to do this, is to enable clipping. Feels like a technicality that puts extra load on the author and also increases the number of captured elements.

So if the element is container only, it's painted content draws into its ancestor's snapshot (as usual) but there is a group pseudo-element generated to mirror its geometry and parent its descendant named elements. If the goal is just to optimize out redundant snapshots, then the browser can do this automatically. If the container has no painted content, we optimize out its snapshot. So I'm hesitant to add this paradigm unless needed for a use-case, for example, the element has painted content which needs to draw into its ancestor instead of underneath its own group pseudo.

[bramus]

I've heard several requests for this. E.g. https://x.com/spinbutton/status/1792914789452140789?s=46&t=0fEqkKvBXH87vG_Sqv-Tbg

[khushalsagar]

I've heard several requests for this.

Sorry I didn't mean use-cases for the feature itself. It's for an approach where requiring a name on the container wouldn't work because the author didn't want to lift the container's painting from its ancestor, just a group pseudo to mirror it's box.

[jakearchibald]

Somewhat related to @bramus' point:

ScreenFlow.mp4

The items in the container are clipped by the container's content box. But, if the developer puts overflow: clip on the group, then they'll be clipping the images of the container.

Maybe the structure needs to be:

• group(container)
  • image-pair(container) etc for the group
  • content(container)
    • group(item) etc

Where content transitions to and from the content box size & position, relative to the parent group.

[vmpstr]

Notes from an internal discussion:

• view-transition-parent should not require view-transition-tree: preserve. In fact, there is some doubt if we actually want view-transition-tree: preserve if we have the parent property, since effects can be achieved with descendant/child selectors
• view-transition-parent should likely be inherited, since that's the common pattern: if I'm parented to foo, I expect my children by default to be parented to foo.
• We discussed which structure to use if there is a mismatch of topology between states. We haven't reached a conclusion but some of the discussed options follow:
  • Use the old state
  • Duplicate the group element, one with only the "old" image and one with the "new" image and parent them at the respective old/new state containers. The transform should still match the old/new states for both groups

[khushalsagar]

The items in the container are clipped by the container's content box. But, if the developer puts overflow: clip on the group, then they'll be clipping the images of the container.

Feels like this is trying to work around the problem which more granular style capture would solve properly? I'm assuming it's the ink overflow from box decorations which becomes part of the images that we don't want to clip.