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

@ydaniv 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.

Regarding your latest examples, I think the syntax is sane, but I would lean towards a slightly different syntax which is more explicit/pedantic and less magical. Your implied grammar is something like:

```
animation-trigger: <single-animation-trigger>+
single-animation-trigger: <trigger-action>? [ <trigger-source> || <trigger-event> ]
trigger-action: play | pause | reset | reverse | ...
trigger-source:  <dashed-ident>
trigger-event: <event-name> ( <event-args>* )
```

If `trigger-action` is omitted, `play` is assumed.

I would make this modification:

```
single-animation-trigger: <trigger-source> <trigger-event> <trigger-action>
```

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.

Nits aside, I think the biggest difference between your proposal and @flackr's is that your proposal places all the trigger-defining properties in the `animation-trigger` property on trigger target (i.e. the animating element), whereas @flackr's proposal puts them in the `event-trigger` and `timeline-trigger` properties on the trigger source (i.e. the event target or the scroller or the in-viewport element).

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.

With this in mind, here are some simple examples expressed under both proposals (with a bit of freestyling), with both longhand and shorthand versions, to make for easier side-by-side comparison:

**Timeline-based:**

```
#source {
  event-trigger: --source;
}
#target-longhand {
  animation: move 1s;
  animation-trigger-source: --source --source;
  animation-trigger-event: viewenter(0.2) viewleave(0.8);
  animation-trigger-action: play pause;
}
#target-shorthand {
  animation: move 1s;
  animation-trigger: --source viewenter(0.2) play --source viewleave(0.8) pause;
}
```

vs.

```
#source-longhand {
  timeline-trigger-name: --source;
  timeline-trigger-source: view();
  timeline-trigger-actions: enter(0.2) play exit(0.8) leave;
}
#source-shorthand {
  timeline-trigger: --source view() enter(0.2) play exit(0.8) leave;
}
#target {
  animation: move 1s;
  animation-trigger: --source;
}
```

**Event-based:**

```
#source {
  event-trigger: --source;
}
#target-longhand {
  animation: move 1s;
  animation-trigger-source: --source --source;
  animation-trigger-event: click() keydown();
  animation-trigger-action: play pause;
}
#target-shorthand {
  animation: move 1s;
  animation-trigger: --source click() play --source keydown() pause;
}
```

vs.

```
#source-longhand {
  event-trigger-name: --source;
  event-trigger-actions: click() play keydown() pause;
}
#source-shorthand {
  event-trigger: --source click() play keydown() pause;
}
#target {
  animation: move 1s;
  animation-trigger: --source;
}
```

Does this accurately capture the two proposals?

-- 
GitHub Notification of comment by szager-chromium
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3190076370 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 22:47:54 UTC