- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Apr 2025 10:28:50 +0000
- To: public-css-archive@w3.org
> Just to check, if I create an Animation with a backwards fill mode, the moment I attach a trigger to it, it takes effect? > > If so, I think it will be treated as being "in effect". In this case, once you attach a trigger it takes care playback for you, so in that case it is "in effect". > And why do we need to tweak the definition of "current animation effect" if an idle trigger already ensures that we're in the before phase? You're right, I took that into consideration, that the animation is initially "in effect", but I figured the tweak is necessary for the case where `playbackRate > 0` and we may be in the "after" phase, and cases like this. So basically to make sure that if the animation may resume/rewind/reverse the algorithm says it's relevant. > Do you mind if we continue this discussion async? I won't be able to join the telcon (timezone). Sure thing, we have a bunch of open issues in `css-animations-2` and `web-animations-2`, most with agenda+. I'd appreciate if you could review those this week and at least mark those we can raise in the weekly meeting, and we can defer/keep async discussion on the rest. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11971#issuecomment-2792290713 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 10:28:51 UTC