- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Sun, 20 Apr 2025 17:16:00 +0000
- To: public-css-archive@w3.org
I agree with @flackr on the behavior: calling `cancel()` on an animation with a trigger should cancel its effect _and_ deactivate its trigger. If `play()` is called on the same animation, while it still has a trigger associated to it, then it's probably expected for the trigger to be activated again. We could say that in this case the trigger is reset to `idle` state, and consequently rewind the animation. I think that's what I'd expect as a developer, and it's compatible with the default-trigger behavior we have today. If the developer wishes to remove the trigger they can always do so explicitly. So for me that answers the question about: "whether to disassociate the trigger on `cancel()`?". What still remains open is deciding how exactly this mechanism works. How should calling `cancel()` on an animation with an associated trigger work so that it becomes completely deactivated? How should calling `play()` on a cancelled animation with an associated trigger so that the trigger is reset to `idle`- which should in turn reset the animation and replay it? If I'm not mistaken, we didn't change anything in `Playing an animation` procedure, and only updated how `update animations and send events` procedure works, to first update triggers. We should probably change `Cancelling an animation` procedure to also account for the associated trigger. And then we can probably add the missing link when `play()` is called on a cancelled animation. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12064#issuecomment-2817261097 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 20 April 2025 17:16:01 UTC