CSS Animation Builder

• GPU-cheap (compositor only) — `transform` (translate, scale, rotate, skew), `opacity`, `filter`. Animating these does not trigger layout or paint; runs at 60fps on weak phones.
• CPU-expensive (triggers paint) — `color`, `background-color`, `border-color`, `box-shadow`. Paint is fast on small areas, slow on large ones.
• CPU-very-expensive (triggers layout) — `width`, `height`, `top`, `left`, `margin`, `padding`, `font-size`. Every frame re-runs layout for the element AND its descendants. Often the source of "the animation drops frames on mobile".

The substitution rule: animate `transform: translateX(100px)` instead of `left: 100px`; animate `transform: scale(1.1)` instead of `width: 110%`. Same visual result, 10-100× cheaper.

• `linear` — constant speed. Feels robotic. Useful for progress indicators, loaders.
• `ease-in` — starts slow, accelerates. Use for "leaving" animations — element gathers momentum as it exits.
• `ease-out` — starts fast, decelerates. Use for "arriving" animations — element snaps into view, settles smoothly. Most-used easing for UI.
• `ease-in-out` — slow at both ends. Smooth but slightly sleepy. Use for "moving from one state to another" without strong start/end emphasis.
• Custom cubic-bezier — `cubic-bezier(0.16, 1, 0.3, 1)` is "soft-out" (apple-like). `cubic-bezier(0.34, 1.56, 0.64, 1)` is "back" (overshoots slightly).
• Spring physics — newer CSS supports `spring()` with stiffness/damping. React Native and SwiftUI spring physics is the model; CSS catching up in 2025-26.

• 0-100 ms — feels instant. Use for hover and active state changes.
• 100-300 ms — feels responsive. Most UI transitions (modal open, panel slide, button feedback).
• 300-500 ms — feels deliberate. "Page transition" or "story step" feel.
• 500+ ms — feels slow. Use only when needed (loading transition, large layout reflow). Test with users; most people prefer faster.
• Stagger — when animating multiple elements, offset their starts by 30-80ms. Otherwise they look like one block; staggered animation feels more refined.

Some users get motion sickness from animation. The OS preference `prefers-reduced-motion` should disable or shorten non-essential animations. Always wrap large animations in `@media (prefers-reduced-motion: no-preference) { ... }` or use `@media (prefers-reduced-motion: reduce) { animation: none; }`.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

• You are designing a new interaction (modal, tooltip, drawer) and want to tune the animation timing and easing visually.
• You inherited animations that "feel janky" and want to identify which properties are causing the cost.
• You are building a design system and want consistent animation tokens across all components.
• You are explaining animation timing to a designer or stakeholder and want a live demo.

• It will not animate JavaScript-controlled values (scroll position, complex interactions). For those, use Framer Motion, GSAP, or imperative JS.
• It will not do parametric / spring physics fully. CSS support for spring() is partial in 2026; use a JS library for advanced spring animation.
• It will not test on real devices. Animation that looks smooth in dev tools may drop frames on a 2018 budget Android. Test on real hardware.
• It will not handle animation orchestration (timeline-based, multi-element coordination). For complex sequences, use a timeline tool (Framer, GSAP timeline).