- From: David A via GitHub <noreply@w3.org>
- Date: Mon, 02 Jun 2025 15:12:39 +0000
- To: public-css-archive@w3.org
> Right, it would be in the idle state. As a result, there would be two different states: "paused by trigger" and "idle with a trigger". From an author's point of view, the only way to get back from "idle with a trigger" to "paused by a trigger" would be to re-associate with the trigger. So I think that's a pretty good argument for having `cancel()` disassociate from any triggers. > +1 to having `cancel()` disassociate the trigger. For other playback APIs, I don't have a particularly strong sense of what the right thing to do is, tbh. I like the idea that `pause()` has the impact of suppressing the trigger(s), but I wouldn't want to treat `pause()` as an exception (though `cancel()` is perhaps arguably already an exception) so I'm inclined to think all the other APIs should have the same disassociation effect, though I can see how the exact opposite makes sense too, i.e. none of them have a disassociation effect. At a (somewhat hand-wavy) higher level, I've been thinking that we are giving authors 2 "modes" of controlling their animations' playback. "Manual" mode in which they need to invoke the playback APIs explicitly and "autopilot" mode in which they set up the trigger conditions and let that take care of controlling the animations' playback. And if, for whatever reason, the author invokes one of the playback APIs, they're "switching into manual mode" (like taking the wheel of a self-driving car :) ) and the trigger(s) will relinquish control of playback. I wondered whether it would help with making a choice here to think about which choice would be less disruptive to revert but it feels to me like the remedy for either choice is the same. If we auto-disassociate now, we could have some optional param, e.g. `play(disassociateTriggers=true)` in the future to allow authors avoid the disassociation. The remedy for not auto disassociating would be equivalent: `play(disassociateTriggers=false)`. I think we've resolved the main question at the heart of this issue. I had filed [11914](https://github.com/w3c/csswg-drafts/issues/11914) earlier about the question of playback APIs disabling/disassociating triggers, So perhaps we could discuss it there? > > Sorry for being dense here, but I'm not quite following this part. Could you elaborate on what "worked well" means here? And how the "none" and "auto" values play into this? Thank you! > > No worries, by "worked well" I meant matching the value of `auto`, which is a valid value for a timeline, explain the default behavior of autoplaying an animation, and also be the default value for the trigger's timeline. So if we scrap the notion of "default trigger" we say CSS animations and `Element.animate()` animations simply automatically call the `play animation` procedure. But we still need an `initial` value for `animation-trigger`, and to define what `animation-trigger-timeline: auto` means. That is what the default trigger managed to tie together in a coherent way. +1. I had a similar feeling that giving CSS animations a trigger by default makes for a cleaner story of how they are played. A bit of trifling case perhaps but if an author specified `animation-trigger` so as to get the initial/default value then supplying the default trigger (rather than no trigger at all) makes sense? -- GitHub Notification of comment by DavMila Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2931203030 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 June 2025 15:12:40 UTC