Re: [csswg-drafts] [css-animations-2] Add declarative syntax for starting an animation in response to an input event (#12029)

@ydaniv sorry for the late reply...

> 1. Currently `animation-trigger` works with timeilnes using the `animation-trigger-timeline` property. And the Trigger is modeled around the concept of a timeline, either time-based (`auto`) or scroll/view with ranges. In this proposal there is no timeline, or rather, there's yet another inner-trigger that triggers an `auto` timeline? So we need to understand how this sits together with the timeline part.

> 2. With timelines, you either specify a timeline using the `*-timeline` property on the source element, and then reused that via `-name` in the trigger, or specify the timeline using an anonymous function in the trigger property, same like animations. In this proposal the source element is defined using `animation-trigger-name` which just defines this element for a trigger but does not says what for. And then on the target element it's wrapped in a `click()` function that specifies the usage.  Shouldn't we have a property on the source element that defines it as a click source, and then it can be used inside triggers? (getting somewhat a deja vu from CSS Toggles here)

My initial thought is that we should specify that `animation-trigger-timeline` has no effect if the animation trigger is event-based. Even `auto` seems confusing to me in this context.

> 3. I assume we want this feature to also play nicely with different types, i.e. `repeat`, `alternate`, `state`. These behaviors, together with click/hover handlers, are many times used with transitions. While it would be nice to have that working with animations, I wonder if we're not missing a chance to have both, but then this requires toggling a selector, which goes back to CSS Toggles again. But maybe if we could define a `click` source with a property, like mentioned in question (1), and then this could perhaps affect something like a native form of `:state()` selector then this could work out?

I'm hoping to avoid involving CSS states, because doing so would make the optimized path (i.e. starting/stopping the animation on the compositor thread without main thread involvement) much more difficult to implement correctly. It is fairly straightforward to figure out on the compositor thread when a discrete input event targets a particular element. It's likely much harder to figure out on the compositor thread when a particular CSS state applies.

As you say, it should be possible to support `repeat`, `alternate`, and `state`, and I'm hoping that's sufficiently expressive for common use cases. I'm open to other ideas, but my primary motivation for this feature is to enable the compositor-thread fast path and I want to be careful not to defeat it.

BTW @ydaniv, if you are interested in getting involved with this proposal, we would be very grateful for your help in drafting a spec PR. Let me know!

-- 
GitHub Notification of comment by szager-chromium
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12029#issuecomment-2822524346 using your GitHub account


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

Received on Tuesday, 22 April 2025 21:29:17 UTC