- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Sun, 27 Apr 2025 08:15:14 +0000
- To: public-css-archive@w3.org
Copying here the discussion from #12064: I have a proposal for handling calls to `cancel()` and `play()` again: - Change the name of Trigger's state `idle` to something else, like `pending`. I think I chose a bad name here which doesn't correctly reflects the behavior of the state. - Add a new Trigger state named `idle`, which behaves as the name suggests, makes the Trigger effectless. - When running [`Cancelling an animation`](https://drafts.csswg.org/web-animations-1/#canceling-an-animation-section) procedure we add an extra step that sets associated trigger's state to `idle`. - Add a step in [`Updating Animation Trigger State`](https://drafts.csswg.org/web-animations-2/#updating-trigger-state) that checks if state is idle, and if so it aborts the procedure. - Add a step in [`Playing an animation`](https://drafts.csswg.org/web-animations-1/#playing-an-animation-section) that checks if the associated trigger's state is `idle`, and if so resets it to `pending`. I think this solves the `cancel()`/`play()` issue and avoids adding any additional complications to the existing model. ---------------- Regarding calls to `play()`/`pause()`/`reverse()`, I keep supporting the proposal of allowing triggers to keep function normally after these methods are invoked, assuming play/pause/reverse tasks are queued in the same manner by both. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11914#issuecomment-2833295790 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 27 April 2025 08:15:15 UTC