Design Review #1061

#1061: CSS View Transitions - Nested View Transition Groups

Opened Feb 26, 2025

こんにちは TAG-さん!

I'm requesting a TAG review of CSS View Transition - Nested View Transition Groups.

View transitions work by generating a pseudo-element tree representing groups of the captured old state & the live new state of a transition. In its current form, the generated tree is "flat" - the original hierarchy in the DOM is lost, and all the captured groups are siblings under a single ::view-transition pseudo-element.

Instead of a flat tree, the author can nest ::view-transition-group pseudo-elements within each other. This is done with a new property, view-transition-group, which when applied on an element with a view-transition-name, defines whether the generated ::view-transition-group gets nested in one of its containers, or it would nest its own participating descendants.

Explainer¹: https://github.com/WICG/view-transitions/blob/main/nested-explainer.md
Specification: https://www.w3.org/TR/css-view-transitions-2/#view-transition-group-prop
WPT Tests: https://wpt.fyi/results/css/css-view-transitions/nested?label=master&label=experimental&aligned
User research: N/A
Security and Privacy self-review²: N/A
GitHub repo: https://github.com/w3c/csswg-drafts/
Primary contacts:
- @vmpstr (Google, Author)
- @noamr (Google, Author)
Organization/project driving the specification: Google
Multi-stakeholder support³:
- Chromium comments: N/A
- Mozilla comments: https://github.com/mozilla/standards-positions/issues/1183
- WebKit comments: https://github.com/WebKit/standards-positions/issues/466
Status/issue trackers for implementations⁴: https://chromestatus.com/feature/5162799714795520

Further details:

I have reviewed the TAG's Web Platform Design Principles
Previous early design review, if any: N/A
Relevant time constraints or deadlines: N/A
The group where the work on this specification is currently being done: CSSWG
The group where standardization of this work is intended to be done (if different from the current group):
Major unresolved issues with or opposition to this specification: N/A
This work is being funded by: Google

Discussions

Discussed Mar 1, 2025 (See Github)

bumped to plenary

Comment by @xiaochengh Apr 14, 2025 (See Github)

Hi @vmpstr, could you clarify a question, in case I misunderstood how this feature works?

In the example in your explainer, the view transition pseudo element tree after using view-transition-group is:

::view-transition
  ::view-transition-group(container)         <-- clip-path applied on this node
    ::view-transition-image-pair(container)  <-- snapshot of container after clip applied
      ::view-transition-old(container)
      ::view-transition-new(container)
    ::view-transition-group(icon)
      ::view-transition-image-pair(icon)
        ::view-transition-old(icon)
        ::view-transition-new(icon)

It appears that clipping has been applied twice: once on the ::view-transition-group(container) pseudo element, and then on container before the snapshot.

While double-clipping doesn't introduce any visible difference, wouldn't the result be wrong if there is e.g. transform or opacity on container, in which case container ends up double-transformed or double-filtered?