- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Sun, 28 May 2023 13:34:19 +0000
- To: public-css-archive@w3.org
Note for @jakearchibald: Forgive me if this has already been discussed, I don't think it has by looking at the previous issues. I wonder if instead of having new events with a slightly different `ViewTransition` object, we could combine this problem with #8687. This would also be a solution to the problem of programmatically extending the MPA transition's `updateCallback`. Let's say that instead of an existing transition object, we had `document.startViewTransition(updateCallback, { existingTransition: 'skip' | 'finish' | 'continue' }` or `document.continueViewTransition` (strawman, as per how I understood the #8687 mindset), where `skip` is the current behavior, `finish` is "wait until previous transition is finished and use end state as old state for this one` and `continue` would be to use whatever the current state is as the old state. In the MPA case, you could do this: ```html <head> function continueTransition() { const transition = document.startTransition(async () => { await extendTransition() }, {existingTransition: 'continue' }); transition.ready().then(() => { ... }); } // Either this: continueTransition(); addEventListener('pageshow', () => continueTransition()); // or the following if we go down the path of a new event: addEventListener('reveal', () => continueTransition()); </head> ``` -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8682#issuecomment-1566142986 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 28 May 2023 13:34:20 UTC