- From: vmpstr via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 May 2024 15:08:24 +0000
- To: public-css-archive@w3.org
There's also the matter of the update callback time here. So, the current events we have are: t0: startViewTransition is called t1: capture is requested** t2: capture completes t3: callback starts*** t4: callback ends t5: pseudos are created and animation is ready to start ** this includes the request being unblocked to propagate wherever it needs to, not just pending *** t2 and t3 are generally the same time, iirc At t5 right now, the animation progress time is 0. The proposal is to set the progress to something like (t5-t0) so the animation conceptually starts when startViewTransition is called. However, we also discussed excluding some times like the capture turnaround (t2-t1). I think we likely also want to exclude callback runtime (t4-t3)? So, would then should the initial progress of the animation at t5 be (t1-t0)? This is reasonable for css animations. However, for web animations that start at the ready promise resolution (t5), it seems a little awkward to start that animation with non-zero progress and presumably only the animations that target the vt pseudos. This makes coordinating multiple animations difficult, imho. -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9839#issuecomment-2107920604 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 13 May 2024 15:08:25 UTC