- From: David A via GitHub <noreply@w3.org>
- Date: Tue, 23 Sep 2025 19:55:52 +0000
- To: public-css-archive@w3.org
In preparation for discussion tomorrow, it might be worth breaking down this issue into 2 specific proposals to resolve on:
1. Specify the syntax of `animation-trigger` as `animation-trigger: trigger(<dashed ident> <actions/behavior>)`
2. Choose between having higher-level ["behaviors"](https://drafts.csswg.org/css-animations-2/#propdef-animation-trigger-behavior) and granular "actions" such as those proposed in [#12611](https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3292998336).
Concerning 2., I am proposing the latter (granular actions) in order to support the mixing and matching of `event-trigger` and `timeline-trigger` as mentioned in Tab & Elika's [proposal](https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3091201201), e.g. "play when clicked, pause or reset when scrolled out of view." These granular actions still allow authors achieve the higher-level behaviors like I demonstrate in this [demo](https://davmila.github.io/sta-demos/explore/) (requires chrome canary with experimental web platform features enabled.)
Lastly, although "let's implement everything" is not always a desirable outcome, I don't think starting out with granular actions necessarily precludes higher-level actions. We could eventually have high-level actions which are spec’d to map to granular actions. E.g. `alternate` could be a keyword that implies { enter: `play-forwards`, exit: `play-backwards`} and must be specified alone, i.e. `trigger(--trigger alternate)` is allowed, but `trigger(--trigger alternate play)` is not.
--
GitHub Notification of comment by DavMila
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3325345645 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 23 September 2025 19:55:53 UTC