- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Nov 2023 17:46:09 +0000
- To: public-css-archive@w3.org
@calinoracation would you have a preference between a model that requires declaring old/new types when you trigger a transition vs setting the new types within the update callback? ```js // If newType is specified, its used as types on the new DOM instead of type. document.startViewTransition(updateCallback, {types: old, newTypes: new}); ``` vs ```js let vt; async function updateCallback() { ... vt.types = new; } vt = document.startViewTransition(updateCallback, {types: old}); ``` Only reason we can think for the latter would be if some components execute script as a part of updateCallback() which you need to figure out the new type. But don't know if that's an issue in practice. The catch though is that timing is subtle to make sure types are updated at the correct spot so they apply when the browser decides view-transition-names in the new DOM. I'm unsure about whether the following would work for instance: ``` vt = document.startViewTransition(updateCallback, {types: old}); vt.updateCallbackDone().then(() => {vt.types = new}); ``` It requires a microtask checkpoint after updateCallback finishes and browser looks for names in the new DOM to ensure `updateCallbackDone` resolves. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9424#issuecomment-1823219393 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 November 2023 17:46:11 UTC