The Web Animations interface provides a handle for playback, cancellation, and completion when a simple CSS state rule is insufficient. A handle is a resource. If a new command supersedes the old one, the old animation must stop or its completion callback may apply obsolete visual state. A completed promise can reject when animation is cancelled, so error handling is part of lifecycle management. Scripted timing does not authorize a save or determine whether content exists; it only stages the presentation of a state already decided elsewhere.
Web Animations Lifecycle and Cancellation
Working case
The case board animates a card from column 29 to column 47 after a successful assignment. The server response updates the card’s data and accessible column label first. A short animation illustrates the new position. Before it finishes, another reviewer reassigns the case, and the local board receives a newer revision. The controller cancels the old handle, computes the current visual target, and starts only the latest movement. When the board unmounts, all owned handles are cancelled. If motion is reduced, the card appears in its final column without a timeline.
Implementation boundary
function mayFinishMotion(activeRevision, completedRevision) {
return activeRevision === completedRevision;
}
console.log(mayFinishMotion(47, 29));
// Output: falseKeep one animation handle per stable item ID, or a bounded collection for independent effects. Cancel an existing handle before replacing it and guard completion callbacks with the item revision or generation. Use finished only for optional cleanup, catching cancellation rather than treating it as a product failure. Keep the final DOM style in CSS or state so cancelled animation does not leave a stale fill effect. When an element is removed, cancel its handle and release references. Avoid triggering layout measurement on every frame; measure once around the state change when a movement needs old and new geometry.
Cost and boundaries
Creating a handle for every item in a long list can consume memory and compositor work even when animations are off-screen. A first-last-invert-play measurement can read layout twice and may force a synchronous layout if mixed with writes. An O(n) batch of 47 cards should be measured as a batch, not inferred from one card. Prefer a small number of active effects and cap simultaneous movement. Track frame time, dropped frames, active handle count, and how often user commands cancel motion; cancellation may be normal behavior.
Failure trace
A cancelled animation rejects finished, and an unhandled rejection appears in error telemetry. A stale completion handler then removes the current card’s class after a newer assignment. Test repeated reassignment, component unmount, a card removed during motion, reduced-motion changes while a handle exists, a server correction arriving out of order, and navigation away from the board. Inspect that no old handle retains a detached element or overwrites the newest revision.
Verification
- Old animation handles are cancelled on replacement.
- Cancellation does not create an unhandled product error.
- Final DOM state reflects the latest revision.
Practice drill
Create one handle for case 62 and replace it twice before either effect finishes. Observe active handle count and guard any finish work by revision. Cancel the current effect during route exit and confirm no unhandled rejection. Toggle reduced motion, then apply a new assignment while a prior effect exists. Profile a batch of 47 cards and reduce simultaneous effects until input remains responsive.
Decision note
Use a scripted handle only when timing control is needed, and scope it to the state owner.
Common Mistakes
- Keeping a detached element through a handle.
- Letting a finish callback overwrite newer state.
- Measuring layout inside each animation frame.
Connected lessons
Build Project: case board motion and route continuity and review Web Development: motion and regional state decisions quiz; follow Motion and View Change Contracts; CSS Motion State and Interruption; View Transition Navigation, Focus, and Fallback; Reduced Motion and Rendering Budget; Browser Execution and Resource Lifecycle; Cooperative Main-Thread Scheduling.
