- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Apr 2025 13:32:30 +0000
- To: public-css-archive@w3.org
With option 1, can you elaborate on how animation.cancel() works? If I cancel before it's triggered? While it's playing? Does it stop the animation from triggering? If so, what is this state and how do I later say that I want it to be triggerable again? When does a trigger become active for a programmatically constructed animation? As soon as the trigger is assigned? For 1iii, element.animate should not immediately start playing the animation, it should only result in a trigger that is armed. For option 2i and 2ii, I think that pause() should just pause the animation in whatever state its in. If it hasn't triggered yet then it wouldn't trigger even if the condition is met until you call play. For 2iii I think it would be reasonable to consider it an error condition and throw an error, this is assuming that we have a default trigger of the document timeline which is "always triggered". I'm leaning towards option 2 where the trigger being active is semi-synonymous with the animation being in a playing state, the trigger being an extension of the playing lifecycle of the animation (e.g. like being in the before phase) which feels easier to reason about. I imagine also that a trigger `once` animation might finish like a normal animation where a trigger `repeat` or `alternate` animation never stops "playing". @ydaniv FYI -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2835262088 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 April 2025 13:32:31 UTC