Re: [csswg-drafts] [css-view-transitions-2] Starting a same-doc view transition while a cross-doc view transition is pending (#9512)

The CSS Working Group just discussed `[css-view-transitions-2] Starting a same-doc view transition while a cross-doc view transition is pending`, and agreed to the following:

* `RESOLVED: A startVT() called on the new page will force-finish an MPA VT even if a frame hasn't painted yet. (startVT() late in the old page is still undefined)`
* `RESOLVED: startVT() on the old doc is ignored if there's an active MPA VT running, but its callbacks are still dispatched`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> khush: We can only have one VT at a time<br>
&lt;Rossen_> ч?<br>
&lt;Rossen_> q<br>
&lt;TabAtkins> khush: So what to do if the page starts a same-doc VT (script calls .startViewTransition) while a cross-doc is running?<br>
&lt;TabAtkins> khush: In same-doc we take latest; if you start a new one it force-finishes the old one<br>
&lt;TabAtkins> khush: Proposal is to do the same<br>
&lt;TabAtkins> khush: Some debate. If you were navigating and just arrived on the page, do you actually want an abrupt transition and then start the new one?<br>
&lt;flackr> q+<br>
&lt;TabAtkins> khush: In the extreme the doc hasn't drawn a frame yet<br>
&lt;TabAtkins> khush: So our proposal is we delay setting up a VT object on the doc until the page has drawn one frame<br>
&lt;TabAtkins> khush: After that, if you call the JS API, the behavior is the same as same-doc transitions, latest wins<br>
&lt;Rossen_> ack flackr<br>
&lt;TabAtkins> flackr: I can think of lots of cases where devs use a transition for an intro animation to the page<br>
&lt;TabAtkins> flackr: It's common to start a transition before the element is drawn, that's why we delay a frame<br>
&lt;TabAtkins> flackr: So your proposal is that even if youc all startViewTransition before the first frame, it cancels the MPA?<br>
&lt;TabAtkins> khush: No the other way. Conceptually the cross-doc transition isnt' set up until a specific point in the doc lifecycle when a frame has painted.<br>
&lt;TabAtkins> khush: Before that, there is no cross-doc view transition.<br>
&lt;TabAtkins> flackr: So in an MPA you've started the setup on the old page. For consistency with frameworks that can do both SPA and MPA, I'd strongly prefer the MPA transition be canceled if you start a SPA VT even before the old page has painted<br>
&lt;TabAtkins> khush: Use-case?<br>
&lt;TabAtkins> flackr: There are frameworks that'll sometimes SPA or MPA depending on various things. Would be hard to work with it only sometimes canceling<br>
&lt;TabAtkins> khush: My problem is, if you do it before the page has drawn a frame, then by design you'll ahve an abrupt transition.<br>
&lt;TabAtkins> flackr: Yeah but that's the same as if you call startVT() before the previous VT was able to do anything useful<br>
&lt;TabAtkins> khush: It's about timing. If we defer it, then anything you do before the page reveal contributes to the state of the DOM<br>
&lt;TabAtkins> (I'm a little lost fwiw.)<br>
&lt;Rossen_> ack fantasai<br>
&lt;TabAtkins> fantasai: Just to confirm we're talking about calling startVT() on the new page, not on the old page?<br>
&lt;TabAtkins> khush: Yes. There's a separate question about what to do with a VT on the old page, but it's very unlikely anyway<br>
&lt;TabAtkins> flackr: I do just think it's still consistent with the SPA form - we *have* already started the cross-doc VT by the time the new page loads.<br>
&lt;TabAtkins> khush: This isn't a hill I want to die on, I can take either resolution. Authors can just not call it if the behavior is wrong.<br>
&lt;TabAtkins> khush: My proposal was just to hopefully get a "right behavior" by default if you didn't think about it well<br>
&lt;TabAtkins> flackr: And my preference is to get a consistent answer between MPA and SPA.<br>
&lt;TabAtkins> flackr: So my proposal is startVT() force-finishes the MPA transition even if it hasnt' captured the first frame yet<br>
&lt;fantasai> TabAtkins: overlapping VTs seems a mistake<br>
&lt;fantasai> TabAtkins: so prefer to do the predictable thing than trying to make it "smart"<br>
&lt;TabAtkins> fantasai: make it clear - startVT() on the *new* page that cancels the MPA transition<br>
&lt;TabAtkins> TabAtkins: Just making it clear - startVT() late in the old page is currently undefined then, right? And we'll figure it out later.<br>
&lt;TabAtkins> khush: Yes. Let's resolve on the new-page startVT() now.<br>
&lt;khush> q+<br>
&lt;Rossen_> ack khush<br>
&lt;TabAtkins> RESOLVED: A startVT() called on the new page will force-finish an MPA VT even if a frame hasn't painted yet. (startVT() late in the old page is still undefined)<br>
&lt;TabAtkins> khush: Could we decide on the old page behavior? Seemed to be consensus on "dont' cancel" - you're leaving the page and capturing the last frame, doesn't make sense to cancel the MPA<br>
&lt;TabAtkins> khush: so proposed: startVT() is ignored on the old doc if there is an active MPA VT<br>
&lt;TabAtkins> flackr: I think you still need to run update, tho.<br>
&lt;TabAtkins> Rossen_: Sounds like there isn't consensus quite yet, then.<br>
&lt;TabAtkins> khush: I'm happy with the resolution, we can bring it up if we find issues.<br>
&lt;TabAtkins> RESOLVED: startVT() on the old doc is ignored if there's an active MPA VT running, but its callbacks are still dispatched<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9512#issuecomment-1802383498 using your GitHub account


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

Received on Wednesday, 8 November 2023 17:57:01 UTC