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

> I think the misunderstanding is over what exactly "stateless" means; in particular, I was thinking more about the internal implementation, which must be stateful for timeline-based triggers, whereas you are referring to the public-facing API which need not reveal that bit of state.

Yes, that's what I was referring to above:

> 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 placing of trigger-related properties:

> In my opinion, it makes more sense for the trigger-defining properties to be on the source rather than the target. The source element is conceptually where the action happens: it receives an input event or it scrolls or it enters/exits the viewport. If we were to polyfill this feature, it would be expressed in terms of event handlers on the source (for timeline triggers, it would be scroll event handlers on scroller). I think the animating element is more of a dumb receiver of signals initiated by the source element.

I absolutely agree, that was also my initial proposal, but the notion before (perhaps in the event-based triggers PR) was that it's preferred to keep the `event-trigger` with minimal sub-properties, but I'm completely onboard with putting all trigger related on the `event-trigger` property.

-------

Regarding the action issue:

> I'd get rid of the implicit play (and any other magically implied values), and enforce a source/event/action ordering, which I find clear and intuitive.

I'd still argue that `play` is redundant, and if we separate trigger declaration-related properties from the definition of the `animation-trigger`, I think we can even go back to the original behaviors. So the syntax can become something like:

### Shorthands
```css
#source {
  event-trigger: --source-play viewenter(0.2), --source-flip viewleave(0.8);
}

#target {
  animation-trigger: alternate --source-play / --source-flip;
}
```

### Longhands
```css
#source {
  event-trigger-name: --source-play, --source-flip;
  event-trigger-action:  viewenter(0.2), viewleave(0.8);
}

#target {
  animation-trigger-behavior: alternate;
  animation-trigger-name: --source-play / --source-flip
}
```
Where `animation-trigger-name` can also be broken down into 2 sub-properties.

Now, if we don't specify the "flipping" event, and the `behavior` is not `once`, we can say that the same event is used, which allows flipping the trigger using a single event, like click:

```css
#source {
  event-trigger: --source click();
}

#target {
  animation-trigger: alternate --source;
}
```

And then the source starts and flips the animation on every click.

So grosso modo bikeshedding, that is my proposal.

-- 
GitHub Notification of comment by ydaniv
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3191262699 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 11:06:25 UTC