vocab.design

motion

Motion blur

also called directional blur (community), blur transition (community), speed blur (community)

Blurring an element along its direction of travel so fast movement reads as speed instead of teleporting, borrowed from film and rare but real in interfaces.

A film camera does not sample instants, it integrates them. The shutter is open for a fraction of each frame, so anything moving during that fraction is recorded as a streak, and a century of watching film has trained everyone to expect the streak. Take it away and fast movement stops reading as movement: the object appears at a series of separate places, which the eye interprets as stuttering rather than speed. That perceptual debt is the whole reason the effect exists, and it is why animation software has a shutter-angle control at all.

Interfaces inherited the expectation without inheriting the mechanism. A browser composites discrete frames and exposes no sub-frame position, so nothing in CSS produces real motion blur; what ships is always a fake. The honest options are a directional blur applied through an SVG filter, a gradient tail trailing the moving element, or a handful of stacked ghost copies at falling opacity. All three are approximations of a smear, all three cost fill rate on the exact frames that are already the busiest, and none of them can be pointed at as a platform feature.

Which raises the fair question of when it is worth it, and the answer is: rarely. Frame rate explains why. Motion blur is how twenty-four frames a second gets away with being twenty-four frames a second, and an interface running at sixty or a hundred and twenty has far less to hide. It earns its place when something crosses a lot of distance in very little time, a card thrown off screen, a carousel flicked hard, a page slamming past, because there the gap between consecutive frames really is large enough to read as a jump. On a two hundred millisecond fade or a button lifting four pixels, there is nothing to smear.

Two things it is not. It is not a fix for jank: dropped frames are irregular by nature, and blurring the ones that did arrive makes a stutter look like a smeared stutter. And it is not free of legibility cost, since the moment it touches text or an icon the content becomes unreadable for the length of the move, which is fine for a card leaving and unacceptable for one arriving. The safe rule is to blur what is departing, keep what is landing sharp, and turn the whole thing off under a reduced-motion preference, where a fast move should not be happening in the first place.

Which word?

If you wantsay
something moves fast enough that a sharp frame looks wrongmotion blur
content should dissolve into blur, not meet an edgeprogressive blur
scroll speed itself should be visiblevelocity skew

Sources