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

> Although this is interesting to support, I wonder if there are specific use-cases you had in mind.

Yes! For example, an animation that is started on a click, but can be ended by a click *or* by leaving the view (similar to how video playback works on Twitter/BlueSky). Using a view trigger to end the animation doesn't necessarily imply that you want it to *start* on a view trigger.

> By comparison, event triggers would presumably only have one "event" which can act as both.

This does depend on the event-trigger-end-type, somewhat. If `exit-start` (bad name, we know), then the event specified by event-trigger-start-type is somewhat reinterpreted: `click` becomes `mousedown` to start and `mouseup` to end, etc.

(This is probably a little controversial of a design, but we think it makes it fairly intuitive to work with.)

> I wonder maybe if the timeline-trigger would then only really need one range and depending on where it's specified, it would react to entering the range or exiting the range.

The two ranges comes from the *current* design for timeline triggers. They just call it the [exit range](https://drafts.csswg.org/css-animations-2/#animation-trigger-exit-range), instead. The use-cases for that seem reasonable, imo - having an animation start when the element comes *fully* into view (a `contain 0% contain 100%` range) but persist as long as the element is *partially* in view (a `cover 0% cover 100%` range), for example.

Note that the initial `auto` value of the `continue-range` property does handle the common case of the two ranges being identical, so you don't need to touch it unless you do want a separate range.

> On a separate note, I think the behavior of "once" and "always" are analogous to animation-iteration-count where you can specify anything from 0 to infinite. Maybe we can do the same here.

Oh, allowing a number to be specified, so an animation could be played exactly twice, for example? Maybe.

I think an issue with that is that, in the current spec (and [proposed event trigger PR](https://github.com/w3c/csswg-drafts/pull/12314/files#diff-d4bbb6f14218df63c7727c884dba84e0103d39de0571ef1f7ab202c0a30e7608R2402)), the two act quite differently in some details. If a `once` animation is running and receives an event trigger, it just ignores it; a `repeat` animation instead resets to the beginning and starts playing again.

But maybe we divined too much intent into the existing PR and these details are somewhat incidental, and instead just simplifying it to being a number of times it's allowed to play could work. On the other hand, while I can easily imagine use-cases for playing a single time and playing as many times as you want, I can't easily imagine wanting an animation that can be played *at most twice*.

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


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

Received on Tuesday, 22 July 2025 21:39:01 UTC