- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Oct 2022 15:50:21 +0000
- To: public-css-archive@w3.org
> I think it's important that finished is at least chained to promise returned from updateDOMCallback so that the author can predict the sequence. That sounds fine. The author could technically wait on both promises in user code but if the common pattern will be to do something after the DOM has been updated and animation finished then resolving after domUpdatedPromise is settled (resolved or rejected) SGTM. @vmpstr @jakearchibald any concerns with this? > Yes, question is how this API behaves when a user navigates back in mid transition? So that animations are reversed and 'end state' is actually previous view. For the same-documents script API this is completely in author's control, since the API itself doesn't have a concept of "back navigation": 1. They could use existing APIs to reverse all the UA generated animations and use the finished API to update the DOM back to the old state. 2. Or call skipTransition() which will draw at least one frame with the final state and then initiate a new transition. #1 seems like the nicer default behaviour so maybe it makes sense to add an API to do this automatically. We'd likely also need to do it automatically for MPA. @ydaniv this seems unrelated to this issue. Would it be ok to discuss this on #7957? -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7956#issuecomment-1295161149 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 28 October 2022 15:50:23 UTC