- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 May 2025 16:41:17 +0000
- To: public-css-archive@w3.org
> Since we're talking about the high-level architecture, I think it makes sense that triggers operate at the playback level and should ideally not need to touch the animation effect timing. Agreed, I've been thinking of a trigger as being similar to an animation whose start time (which is not part of the effect timing) is in the future. > However, taking this a step further, I wonder if it is possible to have triggers be entirely independent of animations such that they exist as external mechanisms that simply call play(), pause(), cancel() etc. on their target animations. I think that would produce behavior that is easy to reason about for all cases. I understand the rationale behind this model, and I think this represents the current direction (option 1) of how animation trigger works. I think we'll have to carefully work through the expectations to avoid any surprises though, as currently we have a very confusing state around cancelation. To this end, it seems like we'd need to update the procedure to play an animation such that if the animation is currently idle and if it has a trigger, it pauses the animation (i.e. "arms" the trigger, though see my later response). Then a second play could start the animation right away if we think this makes sense. I think though that where this gets confusing is what happens when you call pause()? Does this not have any effect if the trigger hasn't happened yet and leave the trigger able to play the animation? Does pausing an animation that has started playing due to the trigger leave it in a state where it will continue playing if the trigger condition happens again? > If we want to distinguish between certain cases where the to-be-triggered animation fills backwards or not (e.g. distinguishing between Element.animate() and CSS animations vs new Animation()) then we could introduce some concept to the trigger like "arming" or whatever which effectively just calls pause() on the associated animation. Calling pause() would result in an active effect even if it was not `fill: backwards` though right? I think we'd have to pause conceptually just before time 0 (do we reflect this in currentTime?) or make the animation start time exclusive if it has a pending trigger. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2845216635 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 1 May 2025 16:41:18 UTC