- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Nov 2023 17:59:17 +0000
- To: public-css-archive@w3.org
> My point is that it's non-trivial to know this difference. I agree that it can be subtle to understand that `updateCallbackDone`'s promise should be used instead of `ready` to impact names applied in the new DOM. I actually assumed authors would intuitively do it as a part of the update callback. Similar to how we expect them to do it in `reveal` which is equivalent to the end of the DOM update in the MPA world. ```js let transition; transition = document.startViewTransition( async () => { updateDOM(); transition.types.Add("bar"); } ``` @calinoracation for dev input on if this is an intuitive way to fix https://github.com/w3c/csswg-drafts/issues/9424. > So in that model, what role does mutable types play in SPA? We name the transition and it's the same transition on the same document, but then allow the developer to rename it? That doesn't seem to align with this model. Yea, I forgot about https://github.com/w3c/csswg-drafts/issues/9424: "use types to select which styles apply to the old DOM and new DOM". If we agree that the use-case is worth solving then mutable types seems like an elegant way to do it and it also works out for the other use-cases we're talking about: - Let authors decide the type based on the new DOM in MPA. - Let authors decide types on the new DOM based on types from the old DOM. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9526#issuecomment-1813005042 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 November 2023 17:59:19 UTC