- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 May 2025 16:10:42 +0000
- To: public-css-archive@w3.org
I'm generally fine with the above direction, with the following questions/reservations: - Using same trigger for multiple animations is probably more common, just like you can reuse a `ViewTimeilne` for multiple animations. If it still makes the flow too complicated then I'm willing to let this go. - Having a `trigger` property on an `Animation` constructor or as property for `Element.animate()` is a very ergonomic API. Could we have that defined as another way for simply invoking the `AnimationTrigger.animations.add(animation)` procedure? - 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. - 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? -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2913162200 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 May 2025 16:10:43 UTC