Motion

Animation is for explaining a change, not for decorating one. Every transition should answer a question the user would otherwise have: where did this come from, what did I just affect, is something still loading. Motion that answers nothing is latency you added on purpose.

Tokens#

:root {
  --dur-instant: 80ms;    /* colour/opacity feedback on a control */
  --dur-fast:    140ms;   /* hover, focus, checkbox, small toggle */
  --dur-base:    220ms;   /* dropdown, tooltip, accordion, small entrance */
  --dur-slow:    320ms;   /* modal, drawer, large panel entrance */
  --dur-slower:  480ms;   /* full-screen or page-level travel only */

  --ease-out:      cubic-bezier(0.16, 1, 0.3, 1);      /* entering: fast start, soft settle */
  --ease-in:       cubic-bezier(0.5, 0, 0.75, 0);      /* exiting: accelerate away */
  --ease-in-out:   cubic-bezier(0.65, 0, 0.35, 1);     /* moving between two on-screen points */
  --ease-standard: cubic-bezier(0.2, 0, 0.2, 1);       /* general UI default */
  --ease-spring:   cubic-bezier(0.34, 1.56, 0.64, 1);  /* overshoots: direct manipulation only */
}

Duration by distance and importance#

Duration scales with how far something travels and how much of the screen it occupies. A 4px colour change and a full-screen drawer cannot share a duration: the first feels sluggish, the second feels violent.

Two asymmetries worth keeping. Exits are faster than entrances, because the user has already decided and is waiting on you. And anything triggered by direct input (a press, a drag) needs feedback inside roughly 100ms or it feels disconnected from the action.

Above ~500ms motion registers as waiting. If a transition needs longer, the problem is usually the amount of travel, not the timing.

Easing by intent#

Never use ease-in for something entering — it starts slow, so the element looks stuck before it moves. Never use the default ease (cubic-bezier(.25,.1,.25,1)) by omission; it is a browser default, not a decision.

Springs overshoot. That is right for something the user physically moved and wrong for a modal or a menu, where the overshoot reads as instability.

What to animate#

Only two property groups are cheap: transform and opacity. They can be handled without recalculating layout or repainting, so they stay smooth under load. Animating a property that changes geometry forces layout on every frame for that element and its subtree.

.panel {
  transition: transform var(--dur-slow) var(--ease-out),
              opacity   var(--dur-base) var(--ease-out);
}
.panel[data-state="closed"] { transform: translateY(8px) scale(0.98); opacity: 0; }
.panel[data-state="open"]   { transform: none;                       opacity: 1; }

Transition named properties, never transition: all. all animates properties you did not intend — including expensive ones added later — and makes the rule impossible to reason about.

The compositor and will-change#

will-change tells the browser to prepare a property for change, typically by promoting the element to its own layer. It is a hint with a real cost: each promoted layer consumes memory, and a permanently promoted element never gets released.

Also remember that transform, filter, opacity < 1 and will-change each create a stacking context, which changes how z-index resolves inside the element.

prefers-reduced-motion#

Reduced motion is a request to remove large, vestibular-triggering movement — not to remove feedback. Stripping all animation loses information: the user no longer knows a panel appeared rather than the page having changed.

/* Blanket kill switch: use only as a floor, then restore what carries meaning. */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
  /* Degrade, do not delete: the panel still announces itself. */
  .panel { transition: opacity var(--dur-fast) linear !important; transform: none !important; }
  .spinner { animation: spin 1s linear infinite !important; }  /* still means "working" */
}

Also honour it in JavaScript before starting an animation:

const reduced = matchMedia("(prefers-reduced-motion: reduce)").matches;
element.animate(reduced ? [{ opacity: 0 }, { opacity: 1 }] : slideKeyframes,
                { duration: reduced ? 120 : 320, easing: "cubic-bezier(.16,1,.3,1)" });

Stagger#

Staggering a list entrance shows that items are separate. It only works with few items and small delays; past that it becomes a queue the user waits through.

li { animation: rise var(--dur-base) var(--ease-out) backwards;
     animation-delay: calc(var(--i) * 30ms); }   /* --i set inline per item */
@keyframes rise { from { opacity: 0; transform: translateY(6px); } }

Stagger the first appearance only. Re-staggering on every data change makes the list feel unstable.

Layout changes: view transitions and FLIP#

Animating layout properties directly is the expensive path. Two techniques get the same result with transforms.

FLIP — First, Last, Invert, Play. Measure the element's position before the change, apply the change, measure again, apply an inverting transform so it appears not to have moved, then remove the transform with a transition. The movement is a composited transform even though the underlying change was layout.

View transitions do this for you. document.startViewTransition() snapshots the old and new states and cross-fades or morphs matched elements:

@view-transition { navigation: auto; }              /* same-document navigations */
.card { view-transition-name: var(--card-id); }     /* unique per element, or the transition breaks */
::view-transition-old(root) { animation-duration: var(--dur-base); }

if (document.startViewTransition) document.startViewTransition(() => applyDomChange());
else applyDomChange();   /* progressive enhancement: the change still happens */

Two constraints. A view-transition-name must be unique among rendered elements at transition time — duplicates abort the transition. And support is uneven, so the DOM update must work without it, as above.

Do not animate#

Review checklist#

• Every duration and easing comes from a token; no inline magic numbers.
• Only transform and opacity are transitioned; no transition: all.
• Entrances use ease-out, exits use ease-in and are shorter.
• prefers-reduced-motion degrades motion to a fade and keeps loading indicators.
• No will-change in a base style.
• Nothing animates on initial load.
• Every animated element still reaches its final state if the animation is skipped — verify by capturing the page after the transition should have finished.