[css-view-transitions-2] Conditionally choose participating elements when onscreen in both DOM states

[khushalsagar]

Consider the following case:

• There is a header in the old DOM which may or may not be onscreen in the new DOM. For example, the page is scrolled because its a fragment navigation.
• If the header is in both DOMs, you want a position animation between the 2.
• If the header is only in the old DOM, you want it to animate with its parent. As if it was never tagged with a name.

The above is very difficult to achieve. Once you've tagged something in the old DOM, it will generate its own ::view-transition-group and will be in a separate snapshot. Authors could try to set a custom animation so the group for the header, making it as-if it's still embedded in its parent's snapshot. But that's very hard, you need to replicate a bunch of animations (transform, opacity, filter) being applied to the VT pseudo displaying the parent's snapshot.

We can add a new CSS property to have the browser do this. Even if it captured a child as a separate snapshot, don't generate pseudos for it unless the name is on both sides. And render it as-if its still embedded within its parent's snapshot.

[vmpstr]

Some of these problems may be solved by hierarchical structure for the pseudo elements. That structure might still need to be conditionally constructed, so we might need another property here, but at least it would be less magical

[khushalsagar]

That structure might still need to be conditionally constructed, so we might need another property here, but at least it would be less magical

Fair. The use-case I saw would require the header's group pseudo to be a child of the ::view-transition-old of its parent. Since the transition would do a slide animation on the old image.

[bcole808]

+1 to optimizing performance by skipping transitions on elements that are not visible within the viewport in either the old or new DOM.

As a developer writing Javascript and CSS, one way I might try to approach this optimization on the Javascript side could be to use Intersection Observer to keep track of when elements are visible in the viewport. Then, if they are visible, conditionally add a view-transition-name to them.

But I realize a shortcoming of that approach is that it only captures element visibility in the old DOM, and misses elements that are not presently visible but may become visible after a transition (such as for a long list of items on a page where items below the fold may need to transition to appear higher up on the page when the list is re-ordered). Those would not receive a view-transition-name in the old DOM and thus may not be animated during a transition.

[bramus]

Duplicate of #8282?

[khushalsagar]

Duplicate of #8282?

I'm not sure, would love your feedback on that. :)

1. This issue was for the use-case where you only want an element to animate if it will be onscreen on both sides. So we'll conceptually put the captured element's snapshot back into its parent if we don't find a matching view-transition-name onscreen in the new DOM. There's an implicit assumption that ignoring offscreen stuff is only needed for morph animations.
2. [css-view-transitions-2] Ignore offscreen elements from participating in transitions #8282 was more general, ignore an element unless its onscreen (or within some margin of the viewport). So you could use it for elements which do exit/entry animations as well.

I think these are 2 distinct use-cases?

[noamr]

Given #8282 (comment), can this be closed @khushalsagar ?

[khushalsagar]

Sure.

The separate use-case in my mind, "we'll conceptually put the captured element's snapshot back into its parent if we don't find a matching view-transition-name onscreen in the new DOM" can be achieved with nesting.