Interruptible animation

An animation is a promise about where something will be in half a second. An interruptible one lets the reader change that promise while it is still being kept. Tap open, change your mind, tap closed, and the sheet turns around from wherever it had reached instead of insisting on arriving first. What makes this feel right is that the new move starts from the current value rather than from the value the old move was aiming at, so there is no jump and no queue: one continuous object that changed its mind, which is exactly what a physical thing under your hand would do.

The alternative is a lockout, and it is easy to ship by accident. A control that ignores input while its animation runs, or that stacks the ignored presses and replays them afterwards, has quietly decided that the motion outranks the person. Half a second is a long time to a reader who already knows what they want, and every dropped or queued press teaches them that the interface is not listening. The rule underneath is simple: the reader outranks the animation. If an input arrives mid-flight, the current position is the new starting point.

Most of this is free on the web, and it is worth knowing why. A CSS transition retargets natively: write a new value while the old transition is running and the browser starts a fresh one from the currently computed value, so a redirected slide is already smooth without any code that knows about interruption. What CSS does not carry across the seam is velocity. The new transition begins at rest, so a fast-moving element stops dead for an instant before setting off again. That is the gap a spring fills. A spring animation is defined by a position and a velocity rather than by a duration and a curve, so handing the current speed into the new spring is the natural spelling of an interruption, and it is why gesture-driven interfaces reach for springs rather than for easing curves.

Three habits keep the promise. Model state rather than steps, so the animation is always running toward the current state instead of playing a scripted move that must finish to be correct. Never freeze input for the duration of a transition, including the pointer events of the thing that is moving. And check the reversal specifically, since it is the case the lockout hides: open then immediately close, drag then release backwards, expand then collapse before the row has finished growing. Under a stated prefers-reduced-motion the whole problem simplifies, because a move with no duration has nothing to interrupt.