Transitions allow the developer to asynchronously mutate the DOM to the next state while the browser presents the visual output of the previous state to the user. This requires suppressing rendering of the DOM being transitioned to prevent presenting intermediate states to the user. The options for this are:

1. Rendering opportunities are paused. The developer can trigger style/layout via script APIs like getComputedStyle but update the rendering loop doesn't run. This is developer observable since script callbacks (like rAF) won't be dispatched.

   The behaviour aligns with how render-blocking works. Cross-document transitions can then rely on render-blocking as an independent feature to control the first paint of the new Document. The animations start once all render-blocked resources are fetched or timed out. The same-document API provides the same contract, rendering opportunities remain paused until the promise returned by updateDOM callback resolves. However this can't be used for scoped transitions since a transition in a sub-tree shouldn't pause rendering for the complete Document.

2. Continue running rendering opportunities but skip painting the DOM tree participating in a transition. From the developer's point of view, rendering is proceeding as usual but the browser internally doesn't paint these updates for the user.

The proposal is to use 1 for root transitions and 2 for scoped transitions.