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

I think there is a pretty good compromise we can come to here.

`viewenter` and `viewleave`, while being quite useful, don't capture all the use cases of `timeline-trigger`. 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`. Having the full expressive power of timelines and ranges is valuable and I think it would be a mistake to forfeit it.

`viewenter` and `viewleave` are also a bit more limited than `ViewTimeline`. For example, the very [issue](https://github.com/w3c/csswg-drafts/issues/8942) where we began discussing this proposal was one of the issues motivating the "[scroll](https://github.com/w3c/csswg-drafts/issues/9367)" keyword for `view()` timelines. I discovered pretty early on that this keyword would be important for a number of use cases, e.g. where you want the start of the range to be based on `contain` but the end to extend to the end of the scrollable region - an example where this is useful is if what you want is a single trigger point or if you only want to trigger the animation from only one scrolling direction. After we landed an experimental implementation in chromium, I tested out some of @bramus 's demos ([fly-in animation](https://codepen.io/bramus/pen/xxMyKqN/caf0db0208f5fc3eec6b13af754949da), [animated sticky](https://codepen.io/bramus/pen/yLZxQVm/7eea0e149606cc511e0108bc7158113e)) and quickly discovered they didn't work so well without the scroll keyword, prompting me to create my forks of these demos and adding the scroll keyword to see how they worked ([my fly-in](https://codepen.io/awogbemila/pen/emYoXqz), [my animated sticky](https://codepen.io/awogbemila/pen/wBvZOVZ)).
I think these are very valid use cases and work quite naturally with `timeline-trigger`.

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`

I initially thought the latter would be entirely disagreeable to @ydaniv but since you indicate that

> I'm completely onboard with putting all trigger related on the `event-trigger` property.

I'm optimistic that this is a more acceptable compromise as I'm essentially going for a similar arrangement with `timeline-trigger`.

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. 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?

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.


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


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

Received on Friday, 15 August 2025 16:46:46 UTC