- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 19:10:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Dealing with promises on old VT object`, and agreed to the following: * `RESOLVED: Keep the existing VT object for MPA transitions; the promises resolve when back from BFCache, ready rejects. acts like a skipped transition when document hides` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: Again, about the old document, when we start a cross-doc VT<br> <TabAtkins> noamr: We fire an event when the doc is about the commit<br> <TabAtkins> noamr: That even tgives an object that lets you control the VT<br> <TabAtkins> noamr: ONe thing it's clear to use you can do is skip the transition<br> <TabAtkins> noamr: Probably also to change the types, once there's an API for that<br> <TabAtkins> noamr: question we ahven't answered is what to do with the promises - finished, ready, updatecallbackdone<br> <TabAtkins> noamr: so one option is that this isn't acutally a VT object, just a controller with a few abilities<br> <TabAtkins> noamr: second option is to give you a proper VT object, the promises resolve when you can no longer run script<br> <TabAtkins> noamr: So if page is persisted and restroed in bfcache, you'd get them resolved/rejected<br> <TabAtkins> noamr: advantage of this is there's no weird new objects, it's just all VT objects.<br> <TabAtkins> noamr: If you want to do cleanup, you can do it<br> <TabAtkins> noamr: And the other VT things just behave as if it was a skipped VT<br> <TabAtkins> noamr: Since we decided we're skipping a VT when it's hiding, bfcache hides the doc, so it'll be consistent there to skip<br> <TabAtkins> noamr: so as far as the old doc is concenred, the transition is skipped when then page is hidden<br> <khush> q+<br> <miriam> ack khush<br> <TabAtkins> khush: i think right now the interface we hav e for script is build with the idea that the old and new docs, and the doc running the animation, are the same. with cross-doc that breaks<br> <TabAtkins> khush: so question is how to expose the new transition to script in the old page where many of the parts don't make sense<br> <bramus> q+<br> <TabAtkins> khush: I think if I was a web author, i'd be more inclined to want an API taht only has the options that make sense<br> <TabAtkins> khush: So I favored an option tha tintroduced a new interface that only has APIs for skipping and setting the types<br> <TabAtkins> khush: So I think the call should be based on what devs find easiest. if it's easier to share code that operates on a full VT object, we can design it so that the nonsense options still do something resonable.<br> <miriam> ack bramus<br> <TabAtkins> khush: but i lean toward new interface<br> <TabAtkins> bramus: i'd like to back up khushal, i'd like a new object<br> <bramus> https://github.com/w3c/csswg-drafts/issues/9888#issuecomment-1930801630<br> <TabAtkins> bramus: I think as an author it doesnt' make sense to expose promises that don't mean anything at all<br> <TabAtkins> bramus: If you converted this code to MPA, only the stuff before document.startViewTransition will be used in the old page; stuff after is in the new page<br> <TabAtkins> bramus: So I think it makes sense to have a different object.<br> <TabAtkins> bramus: I proposed PartialViewTranstion or PendingVT<br> <TabAtkins> bramus: If we do want to keep the full VT object, maybe shoudl expose a property that tells authors what type of VT they're looking at<br> <miriam> ack fantasai<br> <TabAtkins> fantasai: I don't write a lot of JS, but I think what i'd expect is when you're doing single-page VT, you ahve this VT object you hang onto the whole time<br> <TabAtkins> fantasai: I'd expect the multipage to have the same idea conceptually - there's a single VT object that the old page has until it's destroyed then the new page has it<br> <TabAtkins> fantasai: it's not actually the same object, obviously, but it should behave as<br> <TabAtkins> fantasai: So the promises will resolve at the right time of the transition, etc<br> <TabAtkins> fantasai: it's just that your doc will stop existing before some promises resolve<br> <TabAtkins> fantasai: and new doc will start existing after you've called startVT()<br> <vmpstr> q+<br> <khush> q+<br> <TabAtkins> fantasai: But otherwise you can conceptually treate it like it was one object the whole time<br> <TabAtkins> bramus: In that case then I would like some property to tell the author that this is a VT that was carried over from another doc, etc<br> <TabAtkins> fantasai: Yeah that makes sens<br> <TabAtkins> fantasai: but if you're just setting up some listeners, it's okay<br> <TabAtkins> vmpstr: if you bfcache restore, you will restore the actual object, so those listeners will get called with skipped VT<br> <TabAtkins> khush: so you're saying let's pretend the object is persistent across pages<br> <TabAtkins> khush: so when the pseudo-dom is ready, the new page resolves the ready promise, but you want the ready promise to be resolved (canceled) on the old page too<br> <flackr> q+<br> <TabAtkins> khush: it feels odd to have this mental model where events are replicated on old page when they're no longer relevant<br> <TabAtkins> fantasai: so you're suggesting behaving as if you'd ksipped the transitio?<br> <TabAtkins> khush: yes<br> <TabAtkins> fantasai: ah yeah that makes sense<br> <TabAtkins> (treat the old page like it was skipped)<br> <TabAtkins> khush: this is why I thought it was reasonable to only offer the useful APIs on th eold page. Having a promise or callback that only ever fires on the new page seems funky.<br> <TabAtkins> fantasai: Seems simpler to just ahve a single model, then.<br> <khush> q?<br> <khush> q-<br> <fantasai> s/model/API model/<br> <miriam> ack vmpstr<br> <TabAtkins> vmpstr: whatever we decide, it's the ready promise that's a little confusing<br> <TabAtkins> vmpstr: whether that resolves or rejects is a function of whether we ran the animation or not<br> <TabAtkins> vmpstr: and the old doc doesn't know this, only the new doc does<br> <TabAtkins> vmpstr: So i support just not exposing it<br> <noamr> q+<br> <TabAtkins> khush: elika was agreeing with Noam, just consistently reject on the old doc<br> <flackr> q-<br> <TabAtkins> vmpstr: i'm fine with it either way because this is an edge case, it' sjust, pedantically speaking, the consistency isn't there<br> <miriam> ack flackr<br> <TabAtkins> flackr: i do think it makes some sense to attach promises to the event even if it's run on the new page - cleanup, for example, can run on the old page to restore stuff you fiddled with for the transition<br> <TabAtkins> flackr: i'm okay with the ready promise rejecting<br> <TabAtkins> flackr: you woujldn't be doing the cleanup in the ready promise, you'd be waiting for the transition to finish completely<br> <miriam> ack noamr<br> <TabAtkins> noamr: i disagree with the VT object not making sense<br> <TabAtkins> noamr: I think they do make sense<br> <TabAtkins> noamr: It just may be that ready() is about "can you animate this transition", and on the old doc you never can, it'll reject<br> <TabAtkins> noamr: updateCallbackDone() does make sense, it's done because there is none<br> <TabAtkins> noamr: and finished() has a use-case - you might at the start set a bunch of names, and want to remove them on finish<br> <TabAtkins> noamr: so if we don't have a finihed promise you ahve to listen for pagehide() yourself<br> <TabAtkins> noamr: that could be buggy - the event could fire multiple times, etc<br> <flackr> +1<br> <bramus> q+<br> <TabAtkins> noamr: so in general i think APIs do make sense<br> <miriam> ack bramus<br> <TabAtkins> bramus: wouldn't authors do setup of things...<br> <TabAtkins> bramus: you went from old page to new page, then Back Button to return to old page, authors would use pagereveal event to set things up, rather than relying on finished promise?<br> <TabAtkins> noamr: Unrelated, you might not have a transition there, might not do anything on pagereveal.<br> <khush> q+<br> <TabAtkins> noamr: If you have both, we resolve the promises then fire pagereveal, that makes sense<br> <TabAtkins> noamr: You just add a transition, respond to it being finished by undoing things, and ohter bits are consistently redundant<br> <miriam> ack khush<br> <TabAtkins> khush: +1 to finished use-case, i didn't think about it that way<br> <TabAtkins> khush: for bramus's, when you return b->a, you might have code to set up that specific transition, but it might not line up with the setup you did from a->b<br> <TabAtkins> khush: So being able to setup your cleanup immediately and make sure it's correct is good<br> <TabAtkins> khush: Also, bramus's comment about having a property to tell you what half of the transition you're in, that sounds like a good idea<br> <TabAtkins> noamr: if you're in the cross-doc case, you'll get this VT in a pageswap event. We can add the boolean there if we want.<br> <TabAtkins> bramus: I imagine passing the VT to a generic handler that handles both SPA and MPA.<br> <TabAtkins> noamr: The handler there could just take a second parameter itself. but i do find the boolean redundant but harmless<br> <TabAtkins> khush: we could just not have it for now, and if we see it become a common pattern we can add<br> <TabAtkins> noamr: yeah, can resolve separately<br> <TabAtkins> miriam: coming to a resolution?<br> <noamr> Proposed resolution: the promises resolve when back from BFCache, ready rejects. acts like a skipped transition when document hides<br> <TabAtkins> fantasai: want to additionally clarify that we are still using the existing VT interface, not making a new types<br> <TabAtkins> noamr: yup<br> <TabAtkins> miriam: objections?<br> <TabAtkins> RESOLVED: Keep the existing VT object for MPA transitions; the promises resolve when back from BFCache, ready rejects. acts like a skipped transition when document hides<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9888#issuecomment-1939367607 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 19:10:53 UTC