Which events does a CSS keyframe animation dispatch, and when does animationend fail to fire?

## The four events A running keyframe animation reports its lifecycle through DOM events dispatched at the element (or at the originating element, for animations on `::before` / `::after`). All four bubble, so a delegated listener on an ancestor sees them. - **`animationstart`** — fires when the active interval begins, i.e. after `animation-delay` has elapsed. - **`animationiteration`** — fires at the boundary *between* two iterations. It does not fire before the first iteration nor after the last, so an animation with `animation-iteration-count: 3` produces exactly two of them, and one with the default count of `1` produces none. - **`animationend`** — fires once when the animation completes normally. - **`animationcancel`** — fires when the animation stops before completing. ## What each event carries Every one is an `AnimationEvent` with three extra properties: `animationName` (the `@keyframes` name, which is how you tell layered animations apart), `elapsedTime` (seconds the animation has been running, excluding paused time), and `pseudoElement` (`"::before"`, `"::after"` or the empty string). `elapsedTime` has a useful quirk with a negative delay. `animation: float 4s -2s` starts immediately with its clock already two seconds in, and the `animationstart` event fires straight away with `elapsedTime` equal to `2` — the absolute value of the delay — rather than `0`. ```js el.addEventListener('animationstart', (e) => { console.log(e.animationName, e.elapsedTime, e.pseudoElement); }); ``` ## When animationend does not come This is the practical half of the question, because code that cleans up after an animation is usually the code that breaks. **Infinite animations.** `animation-iteration-count: infinite` never completes, so `animationend` never fires. Only `animationstart` and a stream of `animationiteration` events arrive. A cleanup handler waiting on `animationend` for a spinner waits forever. **Cancellation.** If the animation is removed before completing — `animation-name` changes or goes to `none`, the class carrying it is removed, the element becomes un-rendered (`display: none`), the element is detached from the document, or script cancels it — the browser dispatches `animationcancel` instead of `animationend`. Any teardown that only listens for `animationend` leaks: the class is never removed, the promise never settles, the element stays in its half-animated state. **A zero duration.** With `animation-duration: 0s` the animation still starts and ends, so both events fire, but they arrive in the same frame — which is fine for handlers and confusing for anyone timing things by hand. ## Layered animations fire layered events A comma-separated animation list is several independent animations on one element, each with its own lifecycle: ```css .hero { animation: fade-in 400ms ease-out both, float 6s ease-in-out infinite alternate; } ``` Here `animationend` fires once, for `fade-in`, at 400ms, and never for `float`. A naive handler that removes the element on any `animationend` would fire at the wrong moment for the wrong animation. Always branch on `animationName`: ```js el.addEventListener('animationend', (e) => { if (e.animationName !== 'fade-in') return; el.classList.add('is-visible'); }); ``` If two animations in the list touch the same property, the one later in the list wins for that property — the events do not tell you that, so keep layered animations on disjoint properties where you can. ## The robust cleanup pattern When an animation's completion drives real state — removing a toast, unmounting a menu, enabling a button — write the handler so that both terminal events do the teardown, and make the teardown idempotent: ```js const finish = (e) => { if (e.animationName !== 'toast-out') return; el.remove(); }; el.addEventListener('animationend', finish); el.addEventListener('animationcancel', finish); ``` An alternative that collapses all of this is the animation object's `finished` promise from `element.getAnimations()`, which resolves on completion and rejects on cancel — one code path, both outcomes, no name filtering. ## What these events are not for They do not tell you about individual keyframes; there is no "keyframe reached" event. If you need to act at 40% of a motion, either split the animation into two animations with a delay, or read the animation's `currentTime`. And an animation that never starts — a duration of `0s` with a name that never bound, or a keyframes name eaten by the shorthand grammar — produces no events at all, which is itself the most useful diagnostic that something is wrong with the declaration.