Khushal Sagar

One constraint (which I missed above) is that an element participating in a transition must generate a box (can't be `display: none`). When walking through the DOM to identify named...

Thanks for the summary @jakearchibald. +1 to option 1. Toggling of this state mid-transition seems like a bug rather than a pattern the developer would need for a particular UX.

Reiterating the **proposed resolution** : "If constraints on new elements participating in a transition become unsatisfied mid-transition, the transition is aborted." Note that this issue is limited to the behaviour...

Discussed this offline again, the summary above is great. Adding what came up at the last discussion. Option 2 will need to be done anyway for cases like [this](https://developer.chrome.com/docs/web-platform/view-transitions/#transitioning-without-freezing). In...

@flackr was present in the discussion I summarized above for animations/transitions expertise. @rcabanier for compositing/blending expertise since that's what we're trying to decide here: what should be the default isolation/blending...

Resolution aligns with current spec, no work needed.

It sounds like the use-case for a JS API is primarily for same-document navigations where removing the old DOM and populating the new DOM can't be an atomic operation. Does...

As spec'd, startViewTransition will do the following: 1. Render one frame and snapshot it. If no element has a view-transition-name, snapshotting has no cost. Chrome's current implementation might have a...

An explainer clarifying the use-case and a concrete proposal is now available [here](https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md).

> One question on the proposal is if requiring JavaScript to unblock rendering will be a performance bottleneck relative to a more declarative solution? My understanding is that the context...