Re: [csswg-drafts] [css-view-transitions-1] Should the DOMChangeCallback be posted as a task from skip transition steps? (#7904)

> > IMO the callback should be called synchronouosly
> 
> That's not feasible because we can execute this step very late in the [update the rendering](https://html.spec.whatwg.org/#update-the-rendering) steps. Specifically, [step 8.7.5](https://drafts.csswg.org/css-view-transitions-1/#handle-transition-frame:~:text=Return.-,If%20transition%E2%80%99s%20initial%20snapshot%20root%20size%20is%20not%20equal%20to%20the%20snapshot%20root%20size%2C%20then%20skip%20the%20view%20transition%20for%20transition%2C%20and%20return.,-Update%20pseudo%2Delement) :
> 
> ```
> If transition’s initial snapshot root size is not equal to the snapshot root size, then skip the view transition for transition, and return.
> ```
> 
> The "Handle transition frame" algorithm is triggered [here](https://drafts.csswg.org/css-view-transitions-1/#ref-for-perform-pending-transition-operations%E2%91%A0:~:text=For%20each%20fully%20active%20Document%20in%20docs%2C%20perform%20pending%20transition%20operations%20for%20that%20Document.), right before step 16. The goal behind running it this late is that its supposed to reflect DOM changes into the corresponding pseudo-elements. So we want to run it at a point when script is guaranteed to not modify the DOM. But that also means we're at a point where running script is bad. It won't be logically incorrect for this feature but adding a hook where script can run implies the DOM can be dirtied and we'll need to re-run style/layout again.

I don't get why running scripts here is bad? It's not different from running scripts in resize/intersection observers/rAF.

What adding a postTask here would cause is a potential flicker. you'd have a moment where on one hand rendering is allowed ("transition suppressing rendering" is off), and OTOH the update callback wasn't called. 

In the current spec, from the moment you start a transition it is guaranteed that there's no intermediate rendering until the transition is resolved. That's great. With this change, there would be this uncanny-valley moment of "the previous transition has not resolved but rendering is allowed". Of course, we could also put step 5 (Set [transition suppressing rendering](https://drafts.csswg.org/css-view-transitions-1/#document-transition-suppressing-rendering) to false) in that task, but what would we gain? Allowing event/timeout handling while rendering is suppressed, which has to now take the intermediate suppressed state into account?

If we suppress rendering anyway, we might as well do everything synchronously and perform an additional style and layout if needed.

-- 
GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7904#issuecomment-1539739602 using your GitHub account


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

Received on Tuesday, 9 May 2023 09:04:31 UTC