- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 13 May 2026 15:44:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-animations-2][web-animations-2] How should `animation-play-state` interact with `animation-trigger`?``. <details><summary>The full IRC log of that discussion</summary> <fantasai> ydaniv: This is about animation-play-state and animation-trigger.<br> <fantasai> ydaniv: We have default values for animations without a trigger. Animations simply play, because play-state defaults to running<br> <fantasai> ydaniv: If you didn't set play state, and you did set an animation-trigger, then the animation should be paused until triggered.<br> <fantasai> ydaniv: What happens if you set 'play-state: paused'. Should the animation remain paused, or should the trigger override?<br> <fantasai> ydaniv: My proposal is that animation-trigger does not override play-state. If play-state is set to 'running', then the trigger's effect continues as specified<br> <fantasai> ydaniv: And if 'play-state' is set to 'paused' then it overrides and stays paused<br> <fantasai> ydaniv: We have rules when setting properties via imperative API<br> <fantasai> ydaniv: Those override what you have in style<br> <fantasai> ydaniv: But regarding declarative syntax, this is my proposal<br> <fantasai> astearns: This kinda means that changing the default value of animation-play-state overrides triggers?<br> <flackr> q+<br> <fantasai> ydaniv: If you set 'paused' then it overrides. The trigger will not be able to trigger playing forwards or backwards.<br> <astearns> ack flackr<br> <fantasai> flackr: I'm wondering if the simple solution might be for play-action to produce the run state that the animation would normally have<br> <fantasai> flackr: which if the play-state is paused, is paused?<br> <fantasai> flackr: I'm worried about having and tracking overrides<br> <fantasai> flackr: Would prefer to have a simple model that we can reason about<br> <ydaniv> q+<br> <fantasai> flackr: So animation-trigger, any one that would play, would do the animation-play-state action if it hasn't been overridden by the Animations API<br> <fantasai> flackr: That might provide a simpler solution than thinking of it as an override?<br> <astearns> ack ydaniv<br> <fantasai> ydaniv: So do you propose changing the default to something like 'auto' so animation-trigger takes action?<br> <fantasai> flackr: animation-play-state is an input to the animation<br> <fantasai> flackr: My proposal is that we use that input when the play trigger action happens<br> <fantasai> flackr: Don't need a new default value<br> <fantasai> astearns: Rob is proposing that the trigger is not overridden, it just has no effect if animation-play-state is paused<br> <DavidA> q+<br> <fantasai> flackr: When 'play' happens, it'll apply the animation-play-state<br> <fantasai> ydaniv: Initially, simple case of a trigger that plays once.<br> <fantasai> ydaniv: You want the animation to remain paused until it's first triggered<br> <fantasai> ydaniv: But play-state is by default running<br> <fantasai> flackr: That's standard animation trigger<br> <fantasai> ydaniv: Yes, right now it overrides the 'running'.<br> <fantasai> ydaniv: If it takes 'play-state' as input<br> <fantasai> ydaniv: It's still overriding initial state 'paused' when triggered<br> <fantasai> ydaniv: What if that initial state is set to paused. Will that change the behavior, or will the animation trigger get this input and then override?<br> <fantasai> ydaniv: Is there a difference?<br> <fantasai> flackr: If you have 'animation-play-state: paused' when the trigger happens it will leave you with a paused animation.<br> <fantasai> flackr: But it's not that 'animation-play-state: paused' overrides the trigger.<br> <fantasai> flackr: Maybe there's a consistent answer here.<br> <astearns> ack DavidA<br> <fantasai> DavidA: Both ydaniv and flackr's proposals seem they would behave the same<br> <fantasai> DavidA: I see it as using 'animation-play-state: paused' as a way of being in a state where the trigger is associated with the animation, but is not performing any actions.<br> <fantasai> DavidA: [missed]<br> <fantasai> DavidA: The trigger is not taking action on the animation.<br> <fantasai> astearns: What happens when you set 'animation-play-state: paused', you trigger an animation, and then in the time period in which the animation would have done something, you change 'animation-play-state' to 'running'.<br> <fantasai> astearns: Do the two models differ in this scenario?<br> <ydaniv> q+<br> <DavidA> q+<br> <fantasai> flackr: I think pausing an animation from animation-trigger is something that happens during initial style layout update where we create the animation<br> <fantasai> flackr: If you later update state...<br> <fantasai> flackr: That's a good question!<br> <fantasai> flackr: Naively the animation runs, because we missed opportunity to pause it<br> <fantasai> astearns: If animation-play-state overrides the trigger, then it won't run. But if it's input to the trigger, then changing it later would have an effect.<br> <astearns> ack ydaniv<br> <fantasai> ydaniv: I think it's a question of when you change play-state, do you actually calculate the entire state again, or do you just say you missed the opportunity to trigger?<br> <fantasai> ydaniv: So question is whether to specify all the details in this issue<br> <fantasai> ydaniv: or ...<br> <fantasai> ydaniv: There's a lot of technical stuff, so either define there or we can agree on some stuff and follow up<br> <astearns> ack DavidA<br> <ydaniv> scribe+<br> <astearns> ack fantasai<br> <ydaniv> fantasai: wanted to ask about Imperative API that changes state of the animation, can you summarize how that works?<br> <ydaniv> flackr: as soon as you call play() on that animation it ignore style properties<br> <ydaniv> ... just like changing effect etc. on the animation<br> <ydaniv> fantasai: I think what you guys are proposing is that the running state is controlable by animation-trigger<br> <ydaniv> ... but controllabe by aniamtion-trigger and defualts to paused<br> <ydaniv> ... I think you want to be able to control the default state outside, maybe it's a flag on the animation-play-state?<br> <ydaniv> ... maybe it's controllable or not?<br> <weinig> (side question, can someone point me to where in the spec text it says that the attributes set on the Animation IDL object override the CSS ones? I was looking for that for rangeStart/rangeEnd but couldn't immediately find it)<br> <ydaniv> ... seems weird for running to be the overridable and paused overriding<br> <ydaniv> ... let's say I want animation to initally be paused<br> <ydaniv> flackr: that's the default behavior<br> <ydaniv> ... when triggered action occurs, which could be to play the animation<br> <ydaniv> fantasai :so initial state is running, won't it be running by default?<br> <ydaniv> flackr: no when you have a trigger, it overrides initial state<br> <ydaniv> ... my take on what you're expressing with animation-play-state is whether it's disabled or not<br> <ydaniv> +1 to flackr<br> <ydaniv> fantasai: so if nothing happens it will default to running, if instead I have an animation-trigger set up it will not default to running<br> <ydaniv> flackr: yes, it will pause it until triggered<br> <ydaniv> ... the css property will say running<br> <ydaniv> astearns: so it's not really play state...<br> <ydaniv> flackr: it's an input to how you set up the animation<br> <ydaniv> fantasai: but we're stuck with the name<br> <ydaniv> flackr: had an idea we could consider...<br> <ydaniv> ... if you set play-state: paused we just ignore those triggers until set back to running<br> <ydaniv> fantasai: does animation-state-paused ... [missed]<br> <astearns> q?<br> <fantasai> s/[missed]/override the Animations API play state?<br> <ydaniv> qq+<br> <fantasai> [missed discussion with graots]<br> <fantasai> graots: Are you sure you want it to be paused until it's triggered?<br> <fantasai> flackr: Yeah, you want it to not be animating until it's e.g. in-view.<br> <fantasai> graots: Are there not cases where you want it to start playing?<br> <fantasai> flackr: No?<br> <fantasai> flackr: Common case is you start at opacity zero.<br> <fantasai> flackr: You need it to be paused in the before state.<br> <fantasai> graots: Maybe the default state should be the underlying style value<br> <flackr> See last paragraph in https://www.w3.org/TR/css-animations-2/#animation-play-state for override from web animations<br> <fantasai> astearns: Maybe we can figure out an intent?<br> <fantasai> ydaniv: I guess we're converging on the same thing, that it's an enabling or disabling animation<br> <fantasai> ydaniv: But we still need to figure out the technicalities<br> <fantasai> ydaniv: Like changing inside range of triggered timeline<br> <flackr> q+<br> <astearns> ack ydaniv<br> <Zakim> ydaniv, you wanted to react to fantasai<br> <astearns> ack fantasai<br> <ydaniv> fantasai: I don't think spec says what flackr said<br> <ydaniv> ... [reading from spec above]<br> <ydaniv> ... sounds to me like if play-state changes... if WAAPI changes it to playing it should revert it<br> <ydaniv> flackr: when animation is first generated...<br> <ydaniv> ... the last paragraph says it [reading from spec]<br> <ydaniv> ... it's the intent that if you call play/pause on WAAPI it overrides<br> <ydaniv> ... unless the animation gets destroyed, it's a CSSAnimation and removing box, etc...<br> <ydaniv> fantasai: so if you restore it you want to get to the same state<br> <ydaniv> flackr: yes<br> <fantasai> s/get to/cannot get to/<br> <ydaniv> fantasai: I think it's confusing, sounds like we're trying to have a magic state for initial value<br> <ydaniv> ... but once you run a trigger it defaults to on<br> <ydaniv> ... so running means on, and paused means keep paused<br> <ydaniv> ... if we called it enabled/disabled it would be better<br> <ydaniv> astearns: it's not so much about the name but more about how to treat this state<br> <ydaniv> fantasai: maybe both states gets overridden?<br> <DavidA> q+<br> <ydaniv> ... seems confusing like it should be parallel<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <ydaniv> flackr: going to propose a behavior<br> <ydaniv> ... when you have aps: paused, the animation ignores the trigger<br> <fantasai> ... when you change it back to running, it goes back to the "ready to trigger" state. Doesn't start playing.<br> <astearns> ack DavidA<br> <astearns> ack flackr<br> <fantasai> DavidA: Something fantasai mentioned seemed worth exploring. We add a third option which is 'triggered' play state, and only in that state do we control the animation via trigger.<br> <fantasai> DavidA: Then that eliminates the concern about 'paused' and 'running' being asymmetric.<br> <fantasai> DavidA: This would be new, with introduction of animation-trigger<br> <fantasai> astearns: Still need to decide on current value behaviors<br> <fantasai> flackr: If we change initial value, then running and paused would both disable triggers<br> <ydaniv> fantasai: I'm in favor of a new initial value<br> <ydaniv> flackr: I prefer auto<br> <fantasai> flackr: Maybe it can compute<br> <fantasai> flackr: If we had 'triggered' as a different state, then we have to carefully define when you get 'animation-play-state: triggered', which is like some computation based on whether your animation has a trigger.<br> <DavidA> q+<br> <fantasai> flackr: Whereas if we just have 'auto' then 'auto' just means 'runnning' if you don't have a trigger, and 'paused-waiting-for-trigger' if you have a trigger.<br> <fantasai> astearns: We have a shared intent that animation-trigger animations should not run if 'animation-play-state: paused'. How that happens, or whether we rejigger values in 'animation-play-state' we should probably discuss a bit more.<br> <fantasai> astearns: Would like to discuss new values a chance to respond to idea of new values.<br> <fantasai> astearns: So we would figure it out<br> <ydaniv> fantasai: the disadvantage of auto is that we have a lot of those, so maybe another name<br> <flackr> auto is initial, you don't need to use it in the shorthand<br> <ydaniv> ... so have some initial magic value that doesn't compute to itself<br> <ydaniv> ... the behavior that we want is that if it's running it's running, and if it's paused it's paused, and if magic it does the magic of paused initially and then trigger actions apply<br> <fantasai> astearns: Adding values to this property, the property name is a bit misleading. Maybe adding values would not solve that.<br> <ydaniv> astearns: seems like the core problem is the name, so maybe not add a new value but add a new property?<br> <fantasai> fantasai: If we add the new value, I don't think it would be misleading.<br> <ydaniv> fantasai: If we add a new value I don't think it will be misleading<br> <ydaniv> astearns: it's still mapped to the WAAPI properties<br> <ydaniv> fantasai: doesn't matter what we call it, it still gets ignored<br> <fantasai> flackr: We don't need to worry about 'auto' in shorthand, since it's the inital value can just omit it<br> <ydaniv> flackr: we don't need to worry about auto in the shorthand, it's already used for duration<br> <fantasai> flackr: It could compute to itself, because 'animation-play-state: auto' is "I will start an animation if I can"<br> <fantasai> astearns: OK, let's take back to issue.<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12064#issuecomment-4442748965 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 May 2026 15:44:24 UTC