- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Mon, 26 Sep 2022 18:54:20 +0000
- To: public-css-archive@w3.org
> I think it's ok for the transition to be infinite if the developer has deliberately paused the animation. +1. I assumed that the developer may also pause the animation for a particular effect. Infinite animations fall in the same category. We expect the developer will remove them when the intended effect is finished. But idle animations is a good point. We'll need to wait for the step which processes all new animations after it has been set up (either in CSS or JS) to ensure it changes from idle to running state. For example if its start time is unresolved. Does that happen as a part of update-the-rendering loop? After that can an animation still be in idle state? > presumably you'll want to exclude scroll-based animations from this definition too +1. > For animations that don't use CSS/web animations, we'll add some other API for that later. +1 to this as well. We will have a script based API that the developer can use to signal when their animations are done. Technically we could just have that API and the developer can listen to animationfinish events to signal when they're done. So any animations we don't handle automatically will have that fallback. The reason we're doing the automatic detection for this class of declarative animations is developer convenience for common animations APIs on the platform. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1258468906 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 26 September 2022 18:54:22 UTC