On Thu, Jun 11, 2026 at 12:59 PM Mike Taylor <[email protected]> wrote:
> On 6/10/26 1:27 p.m., Chromestatus wrote: > > *Contact emails* > [email protected] > > *Explainer* > https://github.com/w3c/csswg-drafts/issues/9010 > > *Specification* > https://drafts.csswg.org/css-animations-2/#interface-animationevent > > *Summary* > Adds a read-only animation attribute to the AnimationEvent and > TransitionEvent interfaces. This attribute returns the associated Animation > object that triggered the event. > > *Blink component* > Blink>Animation > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAnimation%22> > > *Web Feature ID* > Missing feature > > *Motivation* > When handling CSS animation or transition events (such as animationstart > or transitionend), developers currently only receive metadata like the > animation name or the CSS property name. If they want to programmatically > interact with the triggering animation instance (e.g. to pause it, change > its speed, or use its .finished promise), they must query the element or > document using getAnimations() and filter the results. Providing direct > access to the Animation instance via the animation attribute on the event > object simplifies developer code, avoids costly DOM queries, and aligns > with recent updates to the CSS Animations Level 2 and CSS Transitions Level > 2 specifications. > > *Initial public proposal* > *No information provided* > > *TAG review* > *No information provided* > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: Shipped/Shipping > > *WebKit*: Shipped/Shipping > > *Web developers*: Positive ( > https://github.com/w3c/csswg-drafts/issues/9010) > > *Other signals*: > > *Ergonomics* > The feature is highly ergonomic and straightforward to use. From an > animation event you can get the animation to potentially chain promises > after, modify, etc. > > *Activation* > As Firefox and Safari have already shipped, Chrome shipping should > significantly reduce those activation risks. Developers could detect and > polyfill with something like the following: ``` > element.addEventListener('animationstart', (event) => { const animation = > ('animation' in event) ? event.animation : findAnimationFallback(event); // > Use the animation object... }); Making a perfect polyfill can be > challenging or impossible - as you have to find the matching animation in > element.getAnimations - e.g. if you have the same animation name twice on > an element, it is hard to know which of the animations returned by > getAnimation the animationstart event is for. However, it can be polyfilled > in a way that mostly works using getAnimations. > > *Security* > No security risks, no information is exposed that was not already via > getAnimations. > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > *No information provided* > > > *Debuggability* > This feature arguably will help developers and developer tooling to > associate events with animations and link between them. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > > https://wpt.fyi/results/css?label=master&label=experimental&aligned&q=css%2Fcss-animations%2Fanimationevent%20or%20css%2Fcss-transitions%2Fevents-008%20or%20css%2Fcss-transitions%2Ftransitionevent-interface > > Do we know why the relevant tests are failing, i.e. > https://wpt.fyi/results/css/css-transitions/events-008.html?label=master&label=experimental&aligned > ? > The feature had only just landed, it's passing now :) > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > AnimationEventAnimation > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/40929813 > > *Estimated milestones* > DevTrial on desktop 151 > DevTrial on Android 151 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > *No information provided* > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/6046278267043840?gate=5312243391660032 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a299e72.f2d2b681.29210.054e.GAE%40google.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a299e72.f2d2b681.29210.054e.GAE%40google.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TOp0e-q-RBX%2B9J-U07CMN7FrEhJm4gS%3DgemJxFDxrxOzg%40mail.gmail.com.
