dropdown and no focus management.

4. Pick the properties

• transform and opacity only. They skip layout and paint and run on the GPU. width/height/margin/padding/top/left trigger all three. (clip-path is the sanctioned fourth — see RECIPES.md. height is tolerated only for accordions, where there's no transform equivalent.)
• Never scale(0). Start from scale(0.9–0.97) + opacity: 0. Nothing in the real world appears from nothing.
• transform-origin at the trigger for popovers, dropdowns, menus, tooltips — var(--transform-origin) in Base UI. Modals are exempt; they're not anchored to a trigger, so they stay centered.
• Percentages in translate() are relative to the element's own size — translateY(100%) moves by its own height whatever the content. Prefer over hardcoded pixels.
• In Motion, use the full transform string. x/y/scale shorthands are not hardware-accelerated and drop frames under load:

<motion.div animate={{ x: 100 }} />                          // drops frames under load
<motion.div animate={{ transform: "translateX(100px)" }} />  // hardware accelerated

• Never drive a child's transform from a CSS variable on the parent — it recalculates styles for every child. Set transform on the element directly.

5. Easing and duration — or a spring

Easing, in decision order:

| Situation | Easing |
| --- | --- |
| Entering or exiting | ease-out |
| Moving / morphing on screen | ease-in-out |
| Hover / color change | ease |
| Constant motion (marquee, progress) | linear |
| Default | ease-out |

Never ease-in on UI. It starts slow, delaying the exact moment the user is watching. ease-out at 200ms feels faster than ease-in at 200ms.

Built-in CSS easings are too weak. Use these:

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);        /* strong ease-out for UI */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);    /* strong ease-in-out for on-screen movement */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);     /* iOS-like drawer curve (Ionic) */

Need a curve that isn't here? Take it from easing.dev or easings.co. Don't hand-roll one.

Duration:

| Element | Duration |
| --- | --- |
| Button press feedback | 100–160ms |
| Tooltips, small popovers | 125–200ms |
| Dropdowns, selects | 150–250ms |
| Modals, drawers | 200–500ms |
| Marketing / explanatory | Can be longer |

UI animations stay under 300ms. A 180ms dropdown feels more responsive than a 400ms one.

Reach for a spring instead when the motion is drag with momentum, an element that should feel alive, a gesture the user can interrupt or reverse, or decorative mouse-tracking:

{ type: "spring", duration: 0.5, bounce: 0.2 }        // Apple-style — easier to reason about
{ type: "spring", mass: 1, stiffness: 100, damping: 10 }  // traditional physics — more control

Keep bounce at 0.1–0.3, and avoid bounce in most UI — reserve it for drag-to-dismiss and playful interactions.

6. Interruption and exit

• Transitions, not keyframes, for anything triggered rapidly — toasts, toggles, anything a user can fire twice in a second. Transitions retarget from the current value; keyframes restart from zero.
• Springs for gestures, because they carry velocity through an interruption.
• Exit the way it entered. A toast that slides in from the bottom leaves through the bottom. Symmetric paths are what make swipe-to-dismiss feel obvious.
• Asymmetric timing where the user is deciding. Slow on the deliberate phase (a hold-to-confirm press: 2s linear), snappy on the system response (release: 200ms ease-out).

7. Reduced motion and pointer gating

Ships with the animation, every time.

@media (prefers-reduced-motion: reduce) {
  .element { animation: fade 0.2s ease; } /* keep opacity/color, drop transform-based motion */
}

@media (hover: hover) and (pointer: fine) {
  .element:hover { transform: scale(1.05); } /* touch fires false hovers on tap */
}

const reduce = useReducedMotion();
const closedX = reduce ? 0 : '-100%';

Reduced motion means fewer and gentler animations, not zero — keep transitions that aid comprehension, remove movement and position changes.

Recipes

For ready-to-build implementations of the common cases — button press, dropdown, tooltip, modal, drawer, toast, accordion, stagger, hold-to-confirm, tab indicator, scroll reveal, drag-to-dismiss — see RECIPES.md. Load it whenever the request matches one of those components; start from the recipe rather than from a blank file.

Never Ship

Self-check before you finish. Each of these is an automatic block in review-animations:

| Never | Instead |
| --- | --- |
| transition: all | Name the exact properties |
| transform: scale(0) entrance | scale(0.95) + opacity: 0 |
| ease-in on a UI element | ease-out or a strong custom curve |
| Built-in ease-out on a deliberate animation | cubic-bezier(0.23, 1, 0.32, 1) |
| Animation on a keyboard shortcut or 100+/day action | No animation |
| UI duration over 300ms with no reason | 150–250ms |
| transform-origin: center on a trigger-anchored popover | var(--transform-origin) (modals exempt) |
| Keyframes on toasts, toggles, rapidly-triggered elements | CSS transitions |
| Animating width/height/margin/padding/top/left | transform / opacity |
| Motion x/y/scale props under load | Full transform string |
| Ungated :hover motion | @media (hover: hover) and (pointer: fine) |
| Missing prefers-reduced-motion | Gentler variant, not zero |
| Everything entering at once | 30–80ms stagger |

Output

Write the code. Then, in at most a few lines:

• The gate result — frequency tier and the named purpose. If something in the request was rejected, say which and why.
• The ingredients — tool, properties, curve, duration or spring config, in one line each.
• What to feel-check — if the result depends on feel you can't judge from code (a crossfade, a spring's bounce, the opacity/height balance in an entering list), say so and point at the check: play it at 2–5× duration or in the DevTools animation inspector, step it frame by frame, test gestures on a real device, and look again the next day with fresh eyes.

Don't pad this into a report. The code is the deliverable.

Tone

Opinionated and brief. When the honest answer is "this shouldn't animate," give it — that answer is the reason this skill exists. When feel genuinely can't be settled from code, say so instead of guessing at a value.