Re: [csswg-drafts] [css-animations-2] Move scroll and event animation triggers to independent namespace (#12336)

@DavMila:
> For example, they ignore `ScrollTimeline` - I might want to trigger an animation (e.g. fade a banner/banners out or in) based on the user's scrolling the page/document past `xvh`.

I'd argue that in most cases that you'd want to perform this you'll also have an element that takes that exact area and could be used as a more explicit and correct source as a view timeline for that behavior.
But nonetheless, your argument still stands, and I suppose we could also invent an event for that behavior as @SebastianZ suggested above.

> `viewenter` and `viewleave` are also a bit more limited than `ViewTimeline`. For example, the very https://github.com/w3c/csswg-drafts/issues/8942 where we began discussing this proposal was one of the issues motivating the "scroll" keyword for `view()` timelines.

Yes, I think that could be solved by how we define these events, like adding a keyword argument like `viewenter(start ...)` to specify triggering only when entering from start-edge of view.

> So I think a pretty reasonable compromise is:
>
> * implement `viewenter()` and `viewleave()` events for `event-trigger`, and
> * have `animation-trigger` simply make a reference to a dash ident defined by either an `event-trigger` or a `timeline-trigger`

Maybe, if they still prove useful enough to be specced and implemented although we stick with timeline triggers, then why not.

> I know that you mentioned a "property-in-the-middle" concern earlier but I addressed that many (many) comments back using your example with two different ways that this proposal does not actually necessitate a "property-in-the-middle". In addition to that, @flackr pointed out that we'd support anonymous triggers if you really must do everything in one style rule.

Sure, but I still wanted to take another moonshot at something that could simplify this feature a lot (:

> And finally, maybe this isn't even an issue for you anymore because you're okay with `event-trigger` defining the trigger rather than just the name?

Of course I'm OK, that was [my initial thought](https://github.com/w3c/csswg-drafts/pull/12314#discussion_r2144751535) (:

> One more thing: although we are currently thinking specifically about timeline-trigger and event-trigger, I think we have an opportunity here to recognize a more general issue of the possibility of trigger types that do not particularly work well together. The less stuff/constraints we put on animation-trigger, the easier it'll likely be to incorporate future trigger types.
It also seems to be a much cleaner arrangement of these properties, e.g. declaring multiple triggers on a single animation could be as easy as a space-separated list of dashed idents.

Sure thing. I think it's important to keep all event-related properties on the `event-trigger` shorthand, and anything more specific to the behavior of animations should go into `animation-trigger`, like `behavior`/action`.

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


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

Received on Saturday, 16 August 2025 12:54:01 UTC