[csswg-drafts] [css-view-transitions-2] [scoped] Allow self-participating scopes? (#12319)

skobes-chromium has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-view-transitions-2] [scoped] Allow self-participating scopes? ==
This issue tracks an open question about the behavior of [Scoped View Transitions](https://github.com/WICG/view-transitions/blob/main/scoped-transitions.md). Further context appears in the document [Self-Participating Scopes](https://bit.ly/svt-sps).

**Q: Should we allow a self-participating scope?**

This would allow the scope element to be a participant in its own transition, like this:

```
<div id="scope" style="view-transition-name: S">
  before
</div>
<script>
  scope.startViewTransition(() => {
    scope.innerText = "after";  // cross-fade "before" -> "after"
  });
</script>
```

There is some conceptual circularity because the scope "owns" the `::view-transition` pseudo tree, and the pseudo tree contains a redirected rendering of each participant, including (under this proposal) a redirected rendering of the scope element itself.

Another weirdness about this is that only some of the scope's styles will be transitioned. In this [demo](https://output.jsbin.com/wezitop/quiet) (use Chrome 139+ with experimental web platform features enabled) the `background` is transitioned while the `transform` — which determines placement of the pseudo tree — is applied immediately.

The alternative is to disallow self-participation, which forces the developer to use a separate div:

```
<div id="scope">
  <div id="part" style="view-transition-name: S">
    before
  </div>
</div>
<script>
  scope.startViewTransition(() => {
    part.innerText = "after";  // cross-fade "before" -> "after"
  });
</script>
```

My recommendation is to allow self-participating scopes, to make the simple case more ergonomic.

cc @noamr @vmpstr @flackr @bramus @jakearchibald 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12319 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 June 2025 19:26:30 UTC