- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Apr 2025 08:01:52 +0000
- To: public-css-archive@w3.org
> I think I agree with the proposal overall with one (perhaps significant) difference: I wouldn't say that a trigger's effects are overridden by animation-play-state. I think of it more as the condition for advancing an animation (forwards or backwards, so that it reflects its timeline time) now requires, in addition to animation-play-state, whether its trigger condition has been met. Yes, that's gist of it. I guess "overridden" is less accurate here. > I think where this really makes a difference is when we consider what happens when we have a scroll-based trigger (no time-based triggers for now) and the exit condition is met. With animation-play-state: paused should a repeat trigger still reset the animation? should an alternate trigger still reverse the animation? I think these answers should be yes - which means the trigger isn't really overridden, but in all cases (assuming a waapi call hasn't stopped us from listening to animation-play-state) we would still need animation-play-state to be running to make progress on the animation with time. Yes, agreed. With `alternate` the direction is still flipped, but playback still remains paused and current time remains fixed on the same hold time. > A related question I was thinking about was: when an animation with a state trigger is paused by its trigger upon exiting the exit range, if its animation-play-state is then toggled from running to paused and then back to running should it continue to make progress? I think so. Here I think is where the `animation-play-state` is more sort of overriding the behavior of the trigger. I think the playback state should remain `paused` if it's set that way in CSS, regardless of the trigger's effect. If it's set to `running` then the trigger's effect starts affecting the playback state. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12064#issuecomment-2791900673 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 April 2025 08:01:53 UTC