[css-view-transitions-2] Allow to control whether make a particular group when the named element was there only in one side

[yhatt]

Can I create a named group only when elements with the same name defined by the view-transition-name property, exist in both the before and after transition?

I am trying to figure out how to include an element with marked as view-transition-name: xxx, that exists only in one side of transition, in ::view-transition-group(root) instead of ::view-transition-group(xxx).

I'm developing the tool to create HTML-based presentation slides called Marp, that have slide transitions support powered by View Transitions API. All of transition effects for slides are defined as CSS animations working in ::view-transition-group(root), and the slide author can make a morphing animation like PowerPoint Morph and Keynote Magic Move, by marking morphable elements between 2 slides by view-transition-name CSS property.

In this case, even if there is an element named with view-transition-name: xxx on only one side of the transition, a corresponding ::view-transition-group(xxx) with a simple fade effect is generated. However, this element is rendered in the same position before and after the transition due to the specification of View Transitions API. If the ::view-transition-group(root) has a flashy effect, may feel this element like out of place.

The following slide example sets various transitions when navigating, and view-transition-name property to the inline code in page 2 and 3. (Source)

example.mov

If there is no view-transition-name property on one side of the transition, I want to make that element belong to ::view-transition-group(root). (In above example, transitions when navigating 1 ↔︎ 2 and 3 ↔︎ 4)

I tried to use JavaScript to generate ::view-transition-group() only when the same named view-transition-name property exists on both sides of the transition, but it didn't work out in the end.

I also thought using ::view-transition-old(*):only-child and ::view-transition-new(*):only-child CSS selectors as already explained in https://drafts.csswg.org/css-view-transitions-1/#example-387929ce. However, in situations where this selector can be used, ::view-transition-group() has already been generated. It is not possible to change that group to belong to ::view-transition-group(root) by CSS.

I apologize if this already is achievable. But if not, are there any insights about controlling whether make a particular group when the element named by view-transition-name property was there only in one side of the transition? (e.g. Adding an optional argument to document.startViewTransition to set constraints about generating the view transition group)

[jakearchibald]

If there is no view-transition-name property on one side of the transition, I want to make that element belong to ::view-transition-group(root). (In above example, transitions when navigating 1 ↔︎ 2 and 3 ↔︎ 4)

This isn't currently possible, because the old view is captured before the new view is available.

As a developer, you could create the new view, but detached from the document, then crawl the DOM to see if the new view has an equivalent view-transition-name, and if it doesn't, remove it from the old view. If you do this before calling startViewTransition, you'll get the effect you want.

In future, we want to work on 'nested transitions', which allows you to specify that one ::view-transition-group should be nested within another ::view-transition-group. This might help here, if you could conditionally nest a group in the root group.

[khushalsagar]

In future, we want to work on 'nested transitions', which allows you to specify that one ::view-transition-group should be nested within another ::view-transition-group. This might help here, if you could conditionally nest a group in the root group.

My thoughts exactly, nested transitions groups should help. But this brings up a good point, would authors need this nesting to be conditional based on whether a view-transition-name has both old/new images or only one of them.

[jakearchibald]

would authors need this nesting to be conditional based on whether a view-transition-name has both old/new images or only one of them

That would be the only way to fulfill this use-case as far as I can tell. If the developer knows in advance whether to request nesting or not, they could also just not apply view-transition-name.

I see two ways to add this feature:

view-transition-nesting: if-old-only;

This means the group will be nested if there's only an old state. I guess you could have other values, like if-new-only and if-single-image (which is like if-new-only or if-old-only).

Alternatively:

const viewTransition = document.startViewTransition(updateCallback);
const transitionDetails = await transition.ready;

if (transitionDetails.groups.foo && !transitionDetails.groups.foo.new) {
  transitionDetails.groups.root.append(transitionDetails.groups.foo);
}

…which is an imperative API that lets you trigger the nesting of groups.

[khushalsagar]

I like the declarative way since there is a defined point when the DOM structure is finalized. The transform animation the UA sets on the group is dependent on this nesting so we don't want it to change once the animations have started.

Just one thought, there was a feature request early on for developers to be able to animate snapshots of the old DOM while we're waiting for the new DOM to load. The idea being that exit animations don't need to block on new content loading. And we considered accomplishing this by creating the pseudo DOM, with only view-transition-old images, right after capture is finished. With a feature like this, the pseudo DOM hierarchy will need to change when the new content loads. Should be fine but wanted to mention it.

[yhatt]

I'm glad to see the discussion about this concern going on. I believe my concern would resolve if there was ability to set condition for making groups in the nested view transitions.

Comparing named view transition groups by JS manually, that was mentioned by #8528 (comment), is feeling like a bit of high computational costs to run, and still difficult to control if the page state with updated DOM was unpredictable (e.g. MPA in general, SPA with the unstable state of a page).

Actually view-transition-nesting property sounds good to me if it was available an option like only-both.