Re: [csswg-drafts] [css-animations-2][web-animations-2] How should AnimationTrigger work? (#12119)

The CSS Working Group just discussed `[css-animations-2][web-animations-2] How should AnimationTrigger work?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> DavidA: we have this concept of animation triggers, which is a way to declaratively tie *when* to play/pause to a timeline, same as scroll-driven animations<br>
&lt;TabAtkins> DavidA: end goal is to support scroll-triggered animations<br>
&lt;TabAtkins> DavidA: two appraoches we can do this. different implications for the existing concepts<br>
&lt;TabAtkins> DavidA: one appraoch is thinking about animation triggers as an internal animation mechanism<br>
&lt;TabAtkins> DavidA: the other is triggers as an external thing.<br>
&lt;TabAtkins> DavidA: diff between modesl is their relationship between triggers and play/pause/etc<br>
&lt;TabAtkins> DavidA: for internal, we think of play as arming the trigger, so responsibility is the trigger itself. calling play() just gets the trigger ready, and then when the trigger is satisfied it actually plays<br>
&lt;TabAtkins> DavidA: the exteneral way, the trigger is what invokes play()<br>
&lt;TabAtkins> DavidA: we're not looking for a resolution today, just feedback on which way, if any, the WG would lean towards<br>
&lt;TabAtkins> DavidA: i think that'll inform how a lot of other issues i've filed will resolve<br>
&lt;TabAtkins> DavidA: i can talk about details<br>
&lt;ydaniv> q+<br>
&lt;TabAtkins> fantasai: i think it woudl be confusing if play() didn't make the animation play. i think the second animation makes more sense<br>
&lt;flackr> q+<br>
&lt;TabAtkins> fantasai: coudl imagine an animation easily that the author wants to tirgger on a scorll position, but also have an explicit trigger from the uesr. those shoudl interact in a reasonable way<br>
&lt;Rossen5> ack fantasai<br>
&lt;TabAtkins> DavidA: that would still be accommodated i nthe internal model<br>
&lt;TabAtkins> DavidA: what play() does, if the trigger isn';t armed, play() arms the trigger. if it's armed and tripped, play() starts the animation.<br>
&lt;dandclark> TabAtkins: I don't think that's right, if you have a trigger set up and you're not at the position, but want to have a button to trigger the animation, that won't trigger it in this case<br>
&lt;Rossen5> ack ydaniv<br>
&lt;TabAtkins> ydaniv: on my last issue comment, i tried to enumerate the things i think we already agree on in the behavior. we shoudl solve the behavior first, what we expect<br>
&lt;TabAtkins> ydaniv: like what fantasai asked about<br>
&lt;TabAtkins> ydaniv: and once we agree on the behavior, can decide what the model should be<br>
&lt;TabAtkins> ydaniv: so i enumerated stuff i think we agree on, and rob has a comment on a lot of stuff about how it works with existing animation features, which i also think we have agreement on<br>
&lt;flackr> https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2842322212<br>
&lt;TabAtkins> ydaniv: a couple of issues i think are still open are, what happens with multiple calls to play() with an already activated trigger?<br>
&lt;TabAtkins> ydaniv: and what happens if a user calls reverse()?<br>
&lt;TabAtkins> DavidA: on the first, repeated calls to play(), i think that's what i just talked about - i think the expectation is it would play again if you call it repeatedly<br>
&lt;TabAtkins> DavidA: for reverse(), i think the expectation is also tha tit would play, it's like play() it just auto-reverses it<br>
&lt;TabAtkins> flackr: another important aspect to consider is, if you cancel an animation, it won't have an effect until you play() again. if you construct an animation but don't play() it it wont' ahve an effect<br>
&lt;TabAtkins> flackr: so does assigning a trigger to it make it start having an effect? particularly in the "before" phase?<br>
&lt;Rossen5> ack flackr<br>
&lt;TabAtkins> flackr: that seems surprising. seems like you need some way to "arm" the trigger that's not just implict<br>
&lt;TabAtkins> flackr: also from element.animate() it impliciatly calls play, we wouldn't expect it to start playing<br>
&lt;TabAtkins> flackr: note i'm not looking to address these issues right now<br>
&lt;Rossen5> ack fantasai<br>
&lt;TabAtkins> fantasai: i'd ahve to read the whole thing to have a good sense, but i feel like the trigger should be another actor - the user (via JS) and the trigger, they're both animating on the animation and can each make it play or pause or whatever<br>
&lt;TabAtkins> fantasai: i think those calls interleave in that way, like there's two users that each have access to the play/pause buttons<br>
&lt;TabAtkins> (modulo some questions about the animation being "active" for before effect, etc, I also agree with fantasai initially)<br>
&lt;ydaniv> I had the same model in mind as fantasai<br>
&lt;fantasai> s/animating on the/acting on the/<br>
&lt;TabAtkins> Rossen5: so, what resolution are you looking for?<br>
&lt;TabAtkins> DavidA: none right now, looking for feedback on what model to go with<br>
&lt;TabAtkins> DavidA: [summarizes the models again]<br>
&lt;flackr> ydaniv, fantasai that model naively would mean that the animation isn't in getAnimations, and isn't in the before phase until triggered<br>
&lt;TabAtkins> DavidA: would probably be useful to know that, in the second model (trigger calls play()), to rob's point, we'll need some explicit apis to say when to enable and disable the trigger<br>
&lt;TabAtkins> DavidA: so if people still want to think about it, that's fine, otherwise we can resolve one way or another<br>
&lt;TabAtkins> (I think continuing on the issue and treating this as just raising awareness is just fine.)<br>
&lt;TabAtkins> fantasai: adding extra apis to enable/disable the trigger makes sense tome<br>
&lt;fantasai> s/tome/to me<br>
&lt;TabAtkins> Rossen5: all right, let's come back with a model with those extra APIs<br>
&lt;ChrisL> q+<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2859264740 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 7 May 2025 16:40:15 UTC