Removing a CSS animation class from an element and immediately re-adding it in the same script task does not replay the animation. Why, and what actually restarts it?

## When an animation is created A keyframe animation is not attached to a class or to a DOM mutation. It is attached to the element's **computed `animation-name`**. When style is recalculated and an element's computed `animation-name` gains a name it did not have, an animation is created and starts. When it loses one, that animation is cancelled and disappears. Everything about restarting follows from that. Computed values are not recomputed on every DOM write. The browser batches style recalculation and does it when it needs the result — before rendering the next frame, or when script asks a question that requires up-to-date styles. So a sequence like this: ```js el.classList.remove('shake'); el.classList.add('shake'); ``` never produces two different computed values. Both mutations land before the next recalculation; the value read is `shake` both before and after; nothing was removed and nothing was created. If the animation already finished, it stays finished, and the element sits at its cascaded values (or its fill). ## Fix 1: make the value actually change Force a recalculation between the two writes, so the browser observes `none` and then `shake`: ```js el.classList.remove('shake'); void el.offsetWidth; // read a value that requires up-to-date layout el.classList.add('shake'); ``` The read in the middle is not superstition — asking for a geometry value obliges the browser to bring styles up to date first, which is exactly the observation point the animation machinery needs. It works, but it is opaque, easy to "optimise away" in review, and costs a synchronous style/layout pass. ## Fix 2: swap the name Keep two rules whose `@keyframes` are identical but differently named, and alternate between them. The computed `animation-name` genuinely differs, so the old animation is cancelled and a new one is created with no forced recalculation and no timing tricks. The cost is duplicated keyframes, which is why this is usually done with a small pair of utility classes rather than per component. ## Fix 3: drive the animation object Modern browsers expose the running CSS animations as objects: `element.getAnimations()` returns them, each with `currentTime`, `play()`, `pause()`, `cancel()` and a `finished` promise. Restarting is then explicit: ```js for (const anim of el.getAnimations()) { anim.currentTime = 0; anim.play(); } ``` This is the most direct expression of the intent, needs no forced recalculation, and works whether or not the animation had already finished. Note it acts on the animations currently attached to the element, so it restarts what is there rather than causing a class to reapply. ## What does *not* restart an animation `animation-play-state` is a pause switch, not a rewind. Setting it to `paused` and back to `running` resumes from the elapsed position — the animation's clock was frozen, not reset. Similarly, re-declaring the same `animation` shorthand with the same values, changing `animation-delay`, or bumping `animation-iteration-count` on an animation that already completed does not rewind it, because none of those recreate the animation. One thing that *does* cancel it: the element becoming un-rendered, for example via `display: none`. Restoring it creates a fresh animation, which is why a modal that toggles `display` appears to replay its entrance every time while one that toggles a class does not. ## The events you can observe When an animation is cancelled before completing, the element gets an `animationcancel` event; a completed one gets `animationend`. Watching these while debugging tells you immediately whether the browser is destroying and recreating animations or just leaving one in place — which resolves the "is my restart working" question far faster than staring at the visual result. ## Choosing For one-off attention motion in application code, `getAnimations()` with `currentTime = 0` is the clearest. For a design-system utility that must not depend on script structure, the two-name swap is the most robust. Reserve the forced-recalculation trick for code that must stay in the class-toggling idiom, and comment it — an uncommented `void el.offsetWidth` is deleted by the next reader within a month.