- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 29 Jan 2026 19:34:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-view-transitions-2] Extend `waitUntil` so that it can delay the start of the View Transition (animating phase)``.
<details><summary>The full IRC log of that discussion</summary>
<romain> present-<br>
<andruud3> present-<br>
<andruud3> o/<br>
<dholbert> bramus: a while ago, we resolved on adding a waitUntil method on view transition instance<br>
<dholbert> that lets you delay the view transition from finishing until an extra promise has settled<br>
<dholbert> tim brought up that it's not clear from name that this delays completion<br>
<dholbert> you might think it delays the start of a transition<br>
<dholbert> Good thing is, we sometimes might need to do both things<br>
<dholbert> sometimes you might want to delay the completion; other times you might want to delay the start<br>
<dholbert> right now, to do that, you start a VT, await its ready promise, and then grab all the linked animations and pause them<br>
<dholbert> then await some promise, then unpause all the animations<br>
<dholbert> then the vt gets to start<br>
<dholbert> that workaround is a bit weird, because we added waitUntil to avoid that same hack for the finished promise<br>
<dholbert> (a similar hack was previously how you might do this for finished, before we added waitUntil)<br>
<dholbert> so maybe we should extend waitUntil to let authors specify which phase they care about<br>
<dholbert> syntax could be to extend waitUntil to accept an object, which takes a promise and a phase-specifier<br>
<vmpstr> q+<br>
<dholbert> which would be called back on "ready" or "finished"<br>
<dholbert> which maps to the author-exposed promises<br>
<TabAtkins> q+<br>
<emilio> q+<br>
<dholbert> astearns: are the phases in IRC correct?<br>
<dholbert> astearns: in the example, I see "animating"<br>
<dholbert> astearns: what would the phases be here<br>
<astearns> ack vmpstr<br>
<dholbert> bramus: I see that in the example, I passed in a phase that is spec-internal... need to double-check<br>
<dholbert> vmpstr: I'd like to better understand the prevalence of the use-cases that need this<br>
<dholbert> vmpstr: this is doable but it adds complexity to impls<br>
<dholbert> vmpstr: and authors have options already<br>
<dholbert> vmpstr: e.g. you could style animations to start in a 'paused' state<br>
<dholbert> and then start them when you want with webanimations api<br>
<dholbert> vmpstr: so is this a core use-case or an edge case<br>
<dholbert> bramus: common case is when author wants to delay a VT until an image has loaded<br>
<dholbert> bramus: e.g. in a lightbox<br>
<dholbert> vmpstr: those examples already exist - wait for the image, *then* start the VT<br>
<flackr> ::view-transition { animation-play-state: paused; } .ready::view-transition { animation-play-state: running; } (repeat for each vt animation pseudo)<br>
<astearns> ack emilio<br>
<dholbert> emilio: doesn't the update callback also support returning a promise that would delay the start?<br>
<dholbert> vmpstr: it does, but it has a timeout specified to avoid arbitrary delays<br>
<dholbert> vmpstr: and when you're waiting for network, we try to discourage that<br>
<dholbert> emilio: seems like it could be an option tho?<br>
<dholbert> emilio: this proposal doesn't seem particularly different. This would let you sidestep that timeout<br>
<dholbert> emilio: maybe we add an option to let you remove the timeout?<br>
<dholbert> vmpstr: that's possible... subtle difference is, while the callback is running, you're not producing frames<br>
<dholbert> vmpstr: so there are more implications than just pausing the animation<br>
<dholbert> emilio: I thought that's what this proposal was proposing<br>
<dholbert> vmpstr: only if you're doing a full-screen effect, animating on root etc<br>
<dholbert> vmpstr: but if you just pause animations associated with a smaller VT, rendering would not stop<br>
<dholbert> emilio: bramus can you clarify the intended semantics around start .... or maybe I'm misunderstanding<br>
<astearns> ack TabAtkins<br>
<dholbert> vmpstr: FWIW I think removing the timeout and extending the callback is a viable approach to address this use-case; it's just got different tradeoffs than waitUntil<br>
<dholbert> TabAtkins: small note... for the proposed signature, we shouldn't do a choice of a promise or an object-holding-a-promise<br>
<dholbert> TabAtkins: in IDL, a promise type argument accepts anything<br>
<dholbert> TabAtkins: The options arg needs to be an optional 2nd arg<br>
<astearns> ack dbaron<br>
<Zakim> dbaron, you wanted to mention 2-argument syntax alternative<br>
<dholbert> dbaron: I was gonna say the same thing as TabAtkins, because it seems more readable as a syntax<br>
<bramus> q+<br>
<astearns> ack bramus<br>
<dholbert> bramus: Regarding the "animating" phase in the github example<br>
<dholbert> bramus: that's correct, we want to delay the animation until the specific promise has resolved<br>
<dholbert> bramus: so the VT is in its ready state, and waiting to start the animations until a promise has resolved<br>
<dholbert> astearns: maybe we don't need to add more syntax for this?<br>
<dholbert> bramus: historically we added waitUntil to make this easier at finished time<br>
<dholbert> bramus: odd that we'd force them to do the hack at start time<br>
<emilio> q+<br>
<dholbert> astearns: any concerns with resolving to do this?<br>
<astearns> ack emilio<br>
<dholbert> emilio: I really want to clarify what the semantics of different phases would be<br>
<dholbert> emilio: seems like it wouldn't be equivalent to just a long-running update callback<br>
<dholbert> bramus: one scenario: you could kick off a fetch to get some data<br>
<dholbert> bramus: then start some VTs<br>
<dholbert> emilio: so it's like a pre-delay...<br>
<dholbert> bramus: ...before the animations start playing<br>
<dholbert> emilio: so right now, you call startVT with an async function<br>
<dholbert> emilio: and that delays it, and you block rendering and await some stuff<br>
<dholbert> bramus: and you can see that your page is visually frozen<br>
<dholbert> bramus: whereas if you kick it off and let some stuff happen but hold off the start of the animations playing until promise was settled... it's better<br>
<dholbert> vmpstr: compared to kicking off the fetch first, and when that resolves you start the view transition.,.. you've saved the capture phase<br>
<dholbert> vmpstr: and that's 1.5 animation frames in Chromium that we're trying to optimize<br>
<dholbert> vmpstr: so this doesn't buy you much<br>
<dholbert> vmpstr: you're separating the start of a vt to not-yet-animate<br>
<dholbert> vmpstr: which is a distinction we don't need to have<br>
<dholbert> emilio: so the VT ready promise , which does the snapshot... that would run, then ready would resolve, then the animations are paused until the waitUntilTHing resolves?<br>
<dholbert> bramus: yup<br>
<dholbert> vmpstr: so you're saving the callback running time<br>
<dholbert> vmpstr: but the case that you've presented, you want to fetch some resources first<br>
<dholbert> vmpstr: and the callback to update those resources would typically be quick, just updating your HTML or whatever<br>
<dholbert> vmpstr: so this doesn't feel like a performance or ergonomic win<br>
<dholbert> vmpstr: as compared to flipping the order of fetch and startVT<br>
<dholbert> emilio: feels a bit confusing. If I were to delay startVT, I'd expect the same behavior as a long-running callback<br>
<dholbert> emilio: but you're trying to ...<br>
<dholbert> bramus: so vmpstr is saying to do the fetch first and wait for that to be settled before kicking off the VT<br>
<dholbert> emilio: yeah, and don't you want the resource to be ready at the start of the VT?<br>
<dholbert> bramus: I came up with the image-loading use-case, cross-document VTs where you click on one page into detail page, and you want the image to load<br>
<dholbert> bramus: and if you use blocking=render on the img tag, then it blocks rendering until the parser sees the image, *not* until the image has acctually loaded<br>
<dholbert> bramus: so for the MPA case, in your pageReveal function, there you want to kick off the loading of the actual big image, and hold off the VT from running, and then once the image has loaded, you let it run<br>
<dholbert> emilio: is that blocking=render behavior... does that match what we do for <link>?<br>
<dholbert> emilio: if I do it with link, I expect the stylesheet to load<br>
<dholbert> emilio: if img doesn't do that, that seems bad?<br>
<dholbert> vmpstr: I think render-blocking only blocks until parsing of the element, not the external resource fetch<br>
<dholbert> emilio: for styles, that seems bad?<br>
<dholbert> bramus: don't styles already do that?<br>
<dholbert> emilio: not if you do them via script<br>
<dholbert> astearns: maybe we should wrap up this issue to sort out use-cases and proposed behavior<br>
<dholbert> emilio: yeah. e.g. for cross-document case, you're not blocking the update callback<br>
<dholbert> bramus: it already happened, you already navigated<br>
<dholbert> emilio: so it's more of a pause-until than wait-until<br>
<dholbert> astearns: let's take it back to the issue<br>
<dholbert> astearns: need a bit more justification<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13013#issuecomment-3819860178 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 January 2026 19:34:56 UTC