How to Specify Exact Properties for CSS Transitions: A Complete Guide

Always enumerate specific CSS properties in transition declarations rather than using the catch-all all keyword to ensure GPU acceleration, prevent unintended animations, and maintain smooth interruptibility.

Specify exact properties for CSS transitions to build performant, interrupt-friendly interfaces. The emilkowalski/skills repository—containing design engineering guidelines—emphasizes that enumerating specific properties prevents GPU bottlenecks and layout thrashing. This approach ensures only intended visual states animate, keeping interactions smooth during rapid toggles like button presses or toast notifications.

The Problem with transition: all

Using transition: all is flagged as an anti-pattern across multiple files in the emilkowalski/skills codebase. While convenient, this syntax triggers animations for every property change, including those that force expensive layout recalculations.

GPU Acceleration Limitations

Only transform and opacity changes stay on the GPU compositor. Animating layout-affecting properties like width, margin, or padding forces the browser to repaint, causing jank on lower-end devices. According to /skills/improve-animations/AUDIT.md, the audit explicitly flags that transition: all animates unintended properties off-GPU (lines 74-75).

Unbounded Property Animations

Explicit lists prevent side-effects when new styles are added later. As documented in /skills/review-animations/SKILL.md, transition: all creates an "unbounded property animation" (lines 47-48) that can cause visual glitches when unrelated properties change. The file shows a before/after comparison where removing all eliminates unwanted animations on rapidly-triggered elements (lines 86-87).

How to Specify Exact Properties for CSS Transitions

The repository recommends a three-step workflow to implement precise, maintainable transitions.

Step 1: Identify Changing Properties

Audit your component to determine which properties actually change during the interaction. Limit animations to GPU-friendly properties (transform, opacity) or single layout properties that are cheap to animate on decorative elements only.

Step 2: Define Global Design Tokens

Centralize timing and easing values in CSS custom properties to ensure consistency. The "Where motion lives" section in /skills/improve-animations/SKILL.md recommends storing duration and easing in global tokens like --duration-* and --ease-* (lines 35-36).

:root {
  --duration-fast: 150ms;
  --duration-medium: 200ms;
  --ease-out: cubic-bezier(0.22, 1, 0.36, 1);
}

Step 3: Write Explicit Declarations

Replace all with comma-separated property names. As implemented in /skills/emil-design-eng/SKILL.md, the guidelines explicitly recommend: "Specify exact properties; avoid all" (lines 44-45).

/* Good: Only animating transform and opacity */
.button {
  transition: transform var(--duration-medium) var(--ease-out),
              opacity var(--duration-medium) var(--ease-out);
}

Practical Implementation Examples

The following patterns demonstrate the transition from anti-pattern to best practice.

Anti-pattern: Animating every property

/* This animates color, border, box-shadow, etc., even if they never change */
.button { 
  transition: all 200ms ease-out; 
}

Best practice: GPU-friendly properties

/* Keeps animation on the compositor */
.button {
  transition: transform 200ms var(--ease-out),
              opacity 200ms var(--ease-out);
}

Best practice: Single layout property

/* Acceptable for purely decorative elements */
.accordion-content {
  transition: width 150ms var(--ease-in-out);
}

Summary

• Never use transition: all because it forces layout recalculations and animates unintended properties off the GPU.
• Specify exact properties like transform and opacity to maintain GPU acceleration and smooth 60fps animations.
• Reference /skills/emil-design-eng/SKILL.md and /skills/review-animations/SKILL.md for audit checklists that flag unbounded animations.
• Define global tokens for duration and easing to keep transition values consistent across your codebase.
• Prefer interruptible transitions over keyframes for UI that toggles rapidly, as CSS transitions can retarget from the current state rather than restarting.

Frequently Asked Questions

Is transition: all ever acceptable in production?

No. According to the audit guidelines in /skills/improve-animations/AUDIT.md, transition: all should always be replaced with explicit property lists. Even during rapid prototyping, explicit properties prevent performance regressions that are difficult to debug later.

Which CSS properties are safe to animate?

Focus on transform and opacity, which receive GPU acceleration in all modern browsers. Other properties like width, height, margin, and padding force layout recalculations and should only be animated on non-critical decorative elements or when absolutely necessary.

How do I handle multiple properties with different timings?

Use a comma-separated list in your transition declaration. Each property can have its own duration and easing function. For example: transition: transform 200ms ease-out, opacity 150ms linear;.

Why does interruptibility matter for CSS transitions?

Unlike keyframe animations that restart from the beginning, CSS transitions can retarget from their current state. This means if a user toggles a button rapidly, the animation smoothly reverses or adjusts rather than jumping. This behavior is only reliable when targeting specific properties rather than using all.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}