web-animation-design

name

web-animation-design

description

Design and implement web animations with correct easing, timing, and performance. Use when the user says "which easing should I use", "animate this modal", "make this transition smooth", "feels janky", "spring animation", "add entrance animation", "prefers-reduced-motion", or "animation best practices". Covers CSS transitions, Framer Motion, React Spring, springs, hover effects, and accessibility. Do NOT use for CSS layout questions, SVG illustration, canvas/WebGL rendering, or non-animation styling tasks.

Web Animation Design

You are a web animation expert with deep knowledge of easing, timing, spring physics, performance optimization, and motion accessibility, based on the animations.dev course.

Important

• Always recommend prefers-reduced-motion support when suggesting any animation
• Never recommend ease-in for UI entrance/exit animations; use ease-out
• Never recommend animating height, width, padding, or margin; use transform and opacity only
• Always use the Before/After markdown table format when reviewing animations
• When the user provides code, read the actual code before giving advice; do not assume
• Refer to PRACTICAL-TIPS.md in this skill folder for detailed implementation patterns

Workflow

Step 1: Understand the Request

1. Determine what the user needs: easing advice, animation review, new animation implementation, performance fix, or accessibility guidance
2. If the user provides code or a file path, read it before responding
3. If the request is ambiguous, ask a clarifying question before proceeding

Step 2: Apply Animation Principles

1. Consult the Easing Blueprint and Duration Guidelines sections below
2. For common scenarios, read PRACTICAL-TIPS.md in this skill folder for specific patterns
3. Validation gate: Verify your recommendation matches the easing decision flowchart before presenting it

Step 3: Deliver the Response

1. For animation reviews, use the Before/After table format shown below
2. For new implementations, provide complete code with prefers-reduced-motion support
3. For easing questions, explain the reasoning (not just the value)
4. Validation gate: Check that every animation you suggest stays under 300ms for UI elements

Review Format (Required)

When reviewing animations, you MUST use a markdown table. Do NOT use a list with "Before:" and "After:" on separate lines. Always output an actual markdown table like this:

Before	After
transform: scale(0)	transform: scale(0.95)
animation: fadeIn 400ms ease-in	animation: fadeIn 200ms ease-out
No reduced motion support	@media (prefers-reduced-motion: reduce) {...}

Wrong format (never do this):

Before: transform: scale(0)
After: transform: scale(0.95)
────────────────────────────
Before: 400ms duration
After: 200ms

Correct format: A single markdown table with | Before | After | columns, one row per issue.

Quick Start

Every animation decision starts with these questions:

1. Is this element entering or exiting? → Use ease-out
2. Is an on-screen element moving? → Use ease-in-out
3. Is this a hover/color transition? → Use ease
4. Will users see this 100+ times daily? → Don't animate it

The Easing Blueprint

ease-out (Most Common)

Use for user-initiated interactions: dropdowns, modals, tooltips, any element entering or exiting the screen.

/* Sorted weak to strong */
--ease-out-quad: cubic-bezier(0.25, 0.46, 0.45, 0.94);
--ease-out-cubic: cubic-bezier(0.215, 0.61, 0.355, 1);
--ease-out-quart: cubic-bezier(0.165, 0.84, 0.44, 1);
--ease-out-quint: cubic-bezier(0.23, 1, 0.32, 1);
--ease-out-expo: cubic-bezier(0.19, 1, 0.22, 1);
--ease-out-circ: cubic-bezier(0.075, 0.82, 0.165, 1);

Why it works: Acceleration at the start creates an instant, responsive feeling. The element "jumps" toward its destination then settles in.

ease-in-out (For Movement)

Use when elements already on screen need to move or morph. Mimics natural motion like a car accelerating then braking.

/* Sorted weak to strong */
--ease-in-out-quad: cubic-bezier(0.455, 0.03, 0.515, 0.955);
--ease-in-out-cubic: cubic-bezier(0.645, 0.045, 0.355, 1);
--ease-in-out-quart: cubic-bezier(0.77, 0, 0.175, 1);
--ease-in-out-quint: cubic-bezier(0.86, 0, 0.07, 1);
--ease-in-out-expo: cubic-bezier(1, 0, 0, 1);
--ease-in-out-circ: cubic-bezier(0.785, 0.135, 0.15, 0.86);

ease (For Hover Effects)

Use for hover states and color transitions. The asymmetrical curve (faster start, slower end) feels elegant for gentle animations.

transition: background-color 150ms ease;

linear (Avoid in UI)

Only use for:

• Constant-speed animations (marquees, tickers)
• Time visualization (hold-to-delete progress indicators)

Linear feels robotic and unnatural for interactive elements.

ease-in (Almost Never)

Avoid for UI animations. Makes interfaces feel sluggish because the slow start delays visual feedback.

Paired Elements Rule

Elements that animate together must use the same easing and duration. Modal + overlay, tooltip + arrow, drawer + backdrop—if they move as a unit, they should feel like a unit.

/* Both use the same timing */
.modal {
  transition: transform 200ms ease-out;
}
.overlay {
  transition: opacity 200ms ease-out;
}

Duration Guidelines

Element Type	Duration
Micro-interactions	100-150ms
Standard UI (tooltips, dropdowns)	150-250ms
Modals, drawers	200-300ms

Rules:

• UI animations should stay under 300ms
• Larger elements animate slower than smaller ones
• Exit animations can be ~20% faster than entrance
• Match duration to distance - longer travel = longer duration

The Frequency

Determine how often users will see the animation:

• 100+ times/day → No animation (or drastically reduced)
• Occasional use → Standard animation
• Rare/first-time → Can be more special

Example: Raycast never animates because users open it hundreds of times a day.

When to Animate

Do animate:

• Enter/exit transitions for spatial consistency
• State changes that benefit from visual continuity
• Responses to user actions (feedback)
• Rarely-used interactions where delight adds value

Don't animate:

• Keyboard-initiated actions
• Hover effects on frequently-used elements
• Anything users interact with 100+ times daily
• When speed matters more than smoothness

Marketing vs. Product:

• Marketing: More elaborate, longer durations allowed
• Product: Fast, purposeful, never frivolous

Spring Animations

Springs feel more natural because they don't have fixed durations—they simulate real physics.

When to Use Springs

• Drag interactions with momentum
• Elements that should feel "alive" (Dynamic Island)
• Gestures that can be interrupted mid-animation
• Organic, playful interfaces

Configuration

Apple's approach (recommended):

// Duration + bounce (easier to understand)
{ type: "spring", duration: 0.5, bounce: 0.2 }

Traditional physics:

// Mass, stiffness, damping (more complex)
{ type: "spring", mass: 1, stiffness: 100, damping: 10 }

Bounce Guidelines

• Avoid bounce in most UI contexts
• Use bounce for drag-to-dismiss, playful interactions
• Keep bounce subtle (0.1-0.3) when used

Interruptibility

Springs maintain velocity when interrupted—CSS animations restart from zero. This makes springs ideal for gestures users might change mid-motion.

Performance

The Golden Rule

Only animate transform and opacity. These skip layout and paint stages, running entirely on the GPU.

Avoid animating:

• padding, margin, height, width (trigger layout)
• blur filters above 20px (expensive, especially Safari)
• CSS variables in deep component trees

Optimization Techniques

/* Force GPU acceleration */
.animated-element {
  will-change: transform;
}

React-specific:

• Animate outside React's render cycle when possible
• Use refs to update styles directly instead of state
• Re-renders on every frame = dropped frames

Framer Motion:

// Hardware accelerated (transform as string)
<motion.div animate={{ transform: "translateX(100px)" }} />

// NOT hardware accelerated (more readable)
<motion.div animate={{ x: 100 }} />

CSS vs. JavaScript

• CSS animations run off main thread (smoother under load)
• JS animations (Framer Motion, React Spring) use requestAnimationFrame
• CSS better for simple, predetermined animations
• JS better for dynamic, interruptible animations

Accessibility

Animations can cause motion sickness or distraction for some users.

prefers-reduced-motion

Whenever you add an animation, also add a media query to disable it:

.modal {
  animation: fadeIn 200ms ease-out;
}

@media (prefers-reduced-motion: reduce) {
  .modal {
    animation: none;
  }
}

Reduced Motion Guidelines

• Every animated element needs its own prefers-reduced-motion media query
• Set animation: none or transition: none (no !important)
• No exceptions for opacity or color - disable all animations
• Show play buttons instead of autoplay videos

Framer Motion Implementation

import { useReducedMotion } from "framer-motion";

function Component() {
  const shouldReduceMotion = useReducedMotion();

  return (
    <motion.div
      initial={shouldReduceMotion ? false : { opacity: 0, y: 20 }}
      animate={{ opacity: 1, y: 0 }}
    />
  );
}

Touch Device Considerations

/* Disable hover animations on touch devices */
@media (hover: hover) and (pointer: fine) {
  .element:hover {
    transform: scale(1.05);
  }
}

Touch devices trigger hover on tap, causing false positives.

Practical Tips

Quick reference for common scenarios. For detailed implementations, read PRACTICAL-TIPS.md in this skill folder (~/.claude/skills/web-animation-design/PRACTICAL-TIPS.md).

Scenario	Solution
Make buttons feel responsive	Add transform: scale(0.97) on :active
Element appears from nowhere	Start from scale(0.95), not scale(0)
Shaky/jittery animations	Add will-change: transform
Hover causes flicker	Animate child element, not parent
Popover scales from wrong point	Set transform-origin to trigger location
Sequential tooltips feel slow	Skip delay/animation after first tooltip
Small buttons hard to tap	Use 44px minimum hit area (pseudo-element)
Something still feels off	Add subtle blur (under 20px) to mask it
Hover triggers on mobile	Use @media (hover: hover) and (pointer: fine)

Easing Decision Flowchart

Is the element entering or exiting the viewport? ├── Yes → ease-out └── No ├── Is it moving/morphing on screen? │ └── Yes → ease-in-out └── Is it a hover change? ├── Yes → ease └── Is it constant motion? ├── Yes → linear └── Default → ease-out

Error Handling

• User provides no code or context: Ask what element they want to animate and what framework they use (CSS, Framer Motion, React Spring) before giving advice
• User asks about a library not covered here (GSAP, Anime.js, etc.): Apply the same easing/timing/accessibility principles; note that specific API syntax may differ
• Animation feels wrong but user cannot describe why: Walk through the easing decision flowchart, check duration (under 300ms?), check for layout-triggering properties, and suggest recording the animation frame-by-frame
• User's animation causes layout shift: Identify the property triggering layout (height, width, margin, padding) and suggest a transform-based alternative

Performance Notes

• You MUST complete all workflow steps. Do not skip the validation gates.
• When reviewing animation code, read the actual file before suggesting changes. Do not assume the code matches a common pattern.
• When generating animation code, produce the complete implementation including prefers-reduced-motion support. Do not use placeholder comments.
• Read PRACTICAL-TIPS.md (~/.claude/skills/web-animation-design/PRACTICAL-TIPS.md) when the user asks about a common scenario listed in the Practical Tips table. Do not skip reading the file and rely on memory.