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

I'm posting a summary comment of our position in preparation for discussion tomorrow.

Option 1: Adopt a model largely based on [this comment](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3091201201) and [this comment](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3133075898), representing event-based triggers using `event-trigger-*` properties and timeline-based triggers using a `timeline-trigger-*` properties.
Roughly, the idea is that event triggers and timeline triggers are in separate "namespaces.” The main reason is that having separate namespaces gives us more freedom to define different/future types of triggers.
Pros:
- `timeline-trigger` describes a truer representation of the paired/connected nature of “enter” and “exit”, as opposed to the independent nature of generic events.
- `timeline-trigger` is more syntactically consistent with scroll-driven animations since it allows authors to specify explicit scroll boundaries in the same format as `animation-timeline` and `animation-range`.
- It is likely to be more robust to future types of triggers which may not be compatible with an event model.

Cons:
- Timelines are in 1D, so timeline-trigger would be constrained to 1D.
- It requires a larger number of CSS properties  than option 2 as we’d be specifying more longhands.

Option 2: Adopt a model based on [this comment](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3152479346), [this comment](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3161311617), & [this comment](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3189341221) (and the following discussion)
The general idea is that instead of having separate namespaces, the system works on events and certain scroll configurations cause events (`viewenter()`, `viewexit()`)

Pros:
- It requires a smaller number of CSS properties.
- It can be specified to address the concepts of “entry” and “exit” in 2D.

Cons
- It obfuscates some of the magical properties of timeline-based triggers which, in contrast to event-based triggers, are inherently stateful.
- It potentially makes it more difficult to incorporate future trigger types - everything has to fall into the event paradigm.
- Although it requires fewer CSS properties, it moves all the complexity of specifying a timeline and ranges into functional syntax, so the verbosity isn’t gone - it is only shifted around.

**Proposed resolution**: I propose we adopt option 1 as I think it gives us a simpler conceptual model, albeit at the expense of a longer list of CSS properties. We think that the vast majority of use cases for timeline-trigger are 1D. Note that option 1 would also include the ability to specify anonymous event triggers (`event-trigger(...)`) and  anonymous timeline triggers (`timeline-trigger(..)`) much like timelines can be anonymously specified using `view()` or `scroll()` functions.

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


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

Received on Wednesday, 20 August 2025 02:39:52 UTC