Building Animations

Building Animations turns a request for web motion into implementation code using an ordered design process. It first decides whether motion belongs in the interaction, then names its purpose before selecting tools, properties, curves, and timing. The skill follows Emil Kowalski's animation philosophy and treats declining an unnecessary animation as a valid result.

The frequency gate separates actions used more than 100 times daily, which should remain instant, from frequent interactions that warrant nearly imperceptible motion. Occasional modals, drawers, and toasts can use standard animation; rare onboarding or celebrations get more room for delight. Keyboard-initiated actions are excluded. Moving information that someone is reading or acting on purely for decoration is also rejected.

The implementation sequence chooses the cheapest suitable tool: CSS transitions for state changes and hover, CSS @starting-style for mount entry, CSS animations for predetermined motion, WAAPI for programmatic control, and Motion for springs, layout, exits, or gesture-driven values. Existing easing and duration tokens take precedence over a parallel token system.

Use it to construct a specific animation whose job is feedback, spatial consistency, state indication, bridging a jarring change, explanation, or appropriately rare delight. It is separate from auditing existing code, reviewing a diff, discovering animation opportunities, and React Native work, which belong to companion skills.

When the request is really for a toast, drawer, menu, or dropdown component, the workflow points to pick-ui-library instead of hand-building interaction primitives without focus management. Ready-made recipes cover buttons, tooltips, modals, drawers, accordions, staggered lists, hold-to-confirm controls, tabs, scroll reveals, and drag-to-dismiss interactions.

Inputs are the requested interaction, its usage frequency, and the codebase's existing motion tokens. Output is implementation code followed by a brief explanation of the frequency decision, named purpose, ingredients, and any feel checks that still require observation.

Property guidance favors transform and opacity, permits clip-path for relevant recipes, and tolerates height for accordions. Entrances start near full size rather than scale(0). Trigger-anchored overlays place transform-origin at their trigger; centered modals are exempt. Motion implementations use the full transform string rather than x, y, or scale shorthands, and avoid driving child transforms through parent CSS variables.

Timing guidance uses strong ease-out for entrances and exits, ease-in-out for movement, ease for hover or color, and linear for constant motion. One supplied token is:

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);        /* strong ease-out for UI */

Button feedback falls at 100-160ms, small overlays at 125-250ms, and modals or drawers at 200-500ms; ordinary UI motion should stay below 300ms unless justified. Gestures favor springs that preserve velocity, with modest bounce. Rapidly repeated triggers use transitions so an interrupted animation retargets from its current state. Exits follow entry paths, while deliberate hold actions can use slower progress and fast release feedback.

Reduced-motion variants keep useful opacity or color changes while reducing movement. Hover motion is gated to fine pointers that actually support hover. The final checks reject transition: all, unguarded hover, simultaneous entrances without stagger, unsuitable easing, and missing accessibility handling. Subjective results are checked slowly, frame by frame, with real gestures where needed.

The guidance covers CSS, WAAPI, and Motion, with useReducedMotion for Motion implementations. It refers to component recipes and established easing references rather than inventing curves. Its values are opinionated starting points: installed APIs, project conventions, keyboard alternatives, and accessibility requirements take precedence.