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

@szager-chromium:
> It is appealing to use a single event/action based model for all animation triggers, but it is an awkward fit. 

I don't know how you understood that from what I wrote, I said quite the opposite.

In your answer and in @DavMila's I think I wasn't clear enough since it seems you both misunderstood my proposal, so I'll try to elaborate here, and try to provide a better explanation:

This feature was originally conceived to solve the problem of triggering animations based on elements entering view. This can't be achieved natively today without resorting to `IntersectionObserver` and extra elements. IMHO this is the most common important goal this feature was trying to achieve.
So naturally, we chose to build on top of `ViewTimeline` to achieve this, and why the design shifted towards using a timeline.

But using timelines is not the goal, it's just means to an end. If it complicates the design to make it stateless and fit in with event-based triggers, then it's possible we can simplify this and remove timelines altogether.
What we're interested is the behavior of View Timelines, their ability to track entrance and exit into view, regardless of clipping and transforms etc, but we don't have any use for the timeline itself.
Also note that when we add [Pointer Timelines](https://drafts.csswg.org/pointer-animations-1/) this will become even more complicated to map these into the timeline-based trigger design.

So I suggested dropping the whole usage of timelines here with triggers, and instead, "invent" 2 new events: `viewenter` and `viewleave`. These should probably functions that take arguments that modify them in order to get insets and ranges functionality.
Now, since these events are only concerned with entering and exiting, we can simplify their arguments into taking just taking a number that modifies the amount of entry/exit, quite like `IntersectionObserver`'s `threhshold`.
So that would look like `viewenter(0.2)` for 20% entry of element into view, and `viewleave(0.5)` for 50% exit of element out of view.
When we split the timeline into 2 separate events with 2 separate thresholds, we can also drop the `exit-range` since the `viewleave()` event can define a separate point of exit.

Since these events are stateless, it also simplify the needs for having that state in the trigger. Though the browser may still need to track the view timeline internally, and will probably maintain state in there, the trigger however does not need to account for that state anymore.

----------

Regarding the action/behavior discussion. Well, the starting actions is _always_ "play forwards". So it's kind of redundant to specify it in the syntax, like `play`.
The only thing that changes is the "end" action. So that's why by default the initial value is `once`. And without an end/exit trigger/range that is the default behavior.
When an action _IS_ specified, it specifies how the animation should behave on exit: reset, pause, or reverse direction.

Combining the suggested new events above and these actions we get something along the following examples:

### Once
```css
#source {
   event-trigger: --source;
}

#target {
  animation: move 4s;
  animation-trigger: --source viewenter(0.2);
}
```

### Alternate
```css
#target {
  /* without trying to "magically guess" the end event  to be viewleave(0.2) */
  animation-trigger: --source viewenter(0.2) reverse --source viewleave(0.2);
}
```

### Repeat
```css
#target {
  /* extending the "exit-range" to the full cover range */
  animation-trigger: --source viewenter(0.2) reset --source viewleave(1);
}
```

### State
```css
#target {
  animation-trigger: --source viewenter(0.2) pause --source viewleave(0.2);
}
```

For the general case we still have to specify the source element for both events, because I'm assuming we can drop that property-in-the-middle for declaring a trigger, and be able to only introduce one extra property for declaring the event source.


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


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

Received on Thursday, 14 August 2025 17:43:59 UTC