- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Oct 2022 13:56:54 +0000
- To: public-css-archive@w3.org
> finished will only reject if updateDOMCallback returns a rejected promise. In this case the DOM change failed, so it does not reach a valid end state. Option 2 does sound better. > With option 2, when does the finished promise resolve with respect to updateDOMCallback callback. That's a good point. I think it's important that `finished` is at least chained to promise returned from `updateDOMCallback` so that the author can predict the sequence. > > > There's no concept of 'reverse' for View Transitions. > > Yeah, no such concept right now. There is some discussion on this at #7957 but for now ViewTransitions build on animation primitives which are either active or not. 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. > I figured if some code needs to be executed when we've reached the end state, i.e. DOM has been updated, it should wait on domUpdated promise. It's possible that authors will await the `finished` promise so to not interfere with the animation, both waiting for idle visible state and possibly wishing not to degrade its perf. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7956#issuecomment-1295032952 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 13:56:55 UTC