- From: Yehonatan Daniv via GitHub <noreply@w3.org>
- Date: Sun, 01 Jun 2025 16:02:09 +0000
- To: public-css-archive@w3.org
> > Explicitly calling playback methods will also disassociate any triggers from the animation, so, this will still force a use of some internal flag to run the corresponding procedure, to denote the disassociation, right? Though this is probably better than maintaining a state. > > This is a really good point. I was thinking about this after making my proposal and it got me thinking: why do playback methods (including cancel()) even need to disassociate from the trigger? > > If the trigger is acting at an arm's length and simply invoking play(), pause() etc. and the user interferes by calling pause() / play() etc. then the result is whatever you'd get if you called play() / pause() in that same sequence. If the user wants the trigger to no longer apply, they can disassociate it. Yeah, we've been going about this back and forth, and I see that we still have different opinions about it. I suppose after we moved the state from the animation over to the trigger probably solved most of the issues we had around state. So perhaps now both options are plausible. > > My original concern about cancel() not cancelling things would still be addressed in this model since cancel() would work as usual. The only caveat is that if the user later scrolled etc. the animation might start whereas if cancel() disassociated triggers, that would no longer happen. > > I still think cancel should result in an animation no longer being triggered. When we add an animation to a trigger it sits in a paused state waiting for the trigger, and that explains why it is "relevant" and returned by getAnimations. When you cancel, the animation would no longer be paused right? It would be strange to have two states that a triggered animation could be in. I also agree that `cancel()` should leave the animation in a final state that can not apply any effect unless explicitly reset by the author. ------------ Regarding @birtles' suggestion: > An animation can be controlled by multiple triggers and, provided they have a well-defined evaluation order, the result is just whatever you'd get from calling play / pause / etc. on them in that order. How should that actually work in the following scenarios: - One trigger is tripped to `primary` and then a second trigger trips to `primary`. Should that re-play the animation? Or should the second trip be ignored? - One alternating trigger is set to `inverse` and then another alternating trigger is set to `inverse`. Should the animation be reversed twice so it now plays forward? Or should we change the definition of `alternate`? It seems to me like both cases above force us to make this behavior stateful again. I could see having both a click and view triggers be a possible use-case, but not sure about multiple view triggers. I think this behavior needs more work. -------------- > > I like the idea of constructed Animation's simply not having a trigger and just keep work as is, while CSS and .animate() ones get a new instance of the default trigger. Does that summarize this point correctly? > > I'm not sure that animate() needs a default trigger. I'm not sure CSS does either unless that makes the mapping to CSS default property values simpler. So far defaulting to a trigger with the `DocumentTimeline` worked well as the default behavior. We also need to keep in mind that `timeline` values also include `none` and `auto`, and that is how we modeled that part to be consistent. From the author's perspective this is somewhat transparent. If they set the value to `auto` in CSS or read it then it seems consistent with the default triggering. Besides that, I suppose how this works under the hood is still open to interpretation. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2927460069 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 1 June 2025 16:02:10 UTC