[css-shared-element-transitions-1] Define how rendering is suppressed between DOM changes

[khushalsagar]

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.

[css-meeting-bot]

The CSS Working Group just discussed [css-shared-element-transitions-1] Define how rendering is suppressed between DOM changes, and agreed to the following:

• RESOLVED: Rendering suppression uses render blocking to pause update the rendering loop during a view transition

The full IRC log of that discussion

<dael> Topic: [css-shared-element-transitions-1] Define how rendering is suppressed between DOM changes
<dael> github: https://github.com//issues/7784
<dael> khush: This issue was about one aspect of feature where when switching doc state a to b we allow dev to async update dom w/o presenting to user.
<dael> khush: We had these use cases in wild where you have a frame that you render and flips back to snapshot state. You get intermediate frames before animation
<dael> khush: Question on how to suppress. One is render blocking that draws on HTML. BRowser suppresses rendering opportunities
<dael> khush: When you call script API to start, we snapshot and then suppress rendering opportunities
<dael> khush: Other is we keep running lifecycle but browser doesn't present them. Tha could be confusing so prop blocking
<dael> khush: We are planning scoped transitions where it runs on a dom subtree and then we can't do render blocking. I've linked to a prop there for how we want to manage the rendering with scoped transitions. It's using a cached snapshot but keep running the process and retuning the cach
<dael> khush: Would cause a difference between transition types
<smfr> q+
<dael> khush: Prop is go with render blocking behavior for same document and cross document cases
<astearns> ack smfr
<dael> smfr: Would render blocking, is all JS paused?
<dael> khush: No, not at all. Just the update rendering lop is paused
<dael> smfr: Would set timeout fire?
<dael> khush: Yes. Request animation won't
<dael> smfr: Seems weird to turn off some callbacks but not others
<dael> khush: Steps that are part of update rendering loop are paused. Similar to if document is not visible
<TabAtkins> +1, this seems reasonable to me
<dael> smfr: If you did call request animation frame you'd get the callback after render blocking is off
<dael> khush: Correct. Similar to render blocking for a new page doc. Whole loop doesn't run until resources fetched
<dael> astearns: Is there a definition of what does and does not work when document is not visible? I'm wondering if it's similar or exactly like
<dael> khush: Best would be render blocking in the HTML spec. Poitns to rendering opptys and says browser pauses
<vmpstr> update the rendering, for reference: https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering
<dael> khush: clear definition of what is meant to be fired in render loop so gives precise definition
<dael> smfr: Remind me what triggers unblocking?
<dael> khush: script api you call a function with a callback. async callback where dev does all dom mutations. Promise from that unblocks
<dael> smfr: Are tehre other transitions/animations that can run?
<dael> khush: All animations pause
<dael> smfr: Completion doesn't require an animation to render
<dael> khush: Aim of this callback is for you to do min network work you have to do
<ydaniv> will that freeze video playback as well?
<dael> khush: There is no risk of deadlock b/c dev callback should be waiting on anything dispatched during this
<dael> khush: video playback will freeze
<dael> khush: One of the main reasons is the one frame that runs if you don't pause you get a weird flick where you draw more frames but then anything animated flips back to cahced state
<dael> smfr: Pausing video might be tricky for WK
<dael> khush: I think we impl by the parts of stack running animations not giving them resync
<dael> smfr: We oofload some to OS. You're in the middle of a transform...what happens to timeline of animations for render blocking?
<dael> khush: Time proceeds. Timeline will progress forward. Similar to visiblity where itab is backgrounded you don't draw but when you come back animation draws at current time
<dael> khush: I can see impl tough. Motivating factor is this weird flick where you go forward a bit and then back in time when you move to cached snapshots
<dael> astearns: Sounds like you have concerns smfr. You okay resolving to use render blocking and then open issues as you impl?
<dael> smfr: Yeah, I think so
<dael> astearns: Other opinions on using render blocking?
<dael> astearns: ydaniv is the freezing video what you were looking for?
<dael> ydaniv: Just look weird, same as animations stopping. I guess it will be necessary
<dbaron> s/oofload/offload/
<dael> khush: Prop: Rendering suppression uses render blocking to pause update the rendering loop during a view transition
<dael> astearns: Objections?
<dael> RESOLVED: Rendering suppression uses render blocking to pause update the rendering loop during a view transition

[khushalsagar]

The spec edit has landed so closing this now. There is an open issue in the css spec to move this to the html spec.