본문으로 건너뛰기
cccskills
무료GitHub에 공개

web-animation-design

Use this skill to design and implement purposeful web animations. It helps choose easing and duration for common interactions, improve performance by animating suitable properties, and support people who prefer reduced motion, with practical guidance for CSS and JavaScript approaches.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Design and implement web animations that feel natural and purposeful. Use this skill proactively whenever the user asks questions about animations, motion, easing, timing, duration, springs, transitions, or animation performance. This includes questions about how to animate specific UI elements, which easing to use, animation best practices, or accessibility considerations for motion. Triggers on: easing, ease-out, ease-in, ease-in-out, cubic-bezier, bounce, spring physics, keyframes, transform, opacity, fade, slide, scale, hover effects, microinteractions, Framer Motion, React Spring, GSAP, CSS transitions, entrance/exit animations, page transitions, stagger, will-change, GPU acceleration, prefers-reduced-motion, modal/dropdown/tooltip/popover/drawer animations, gesture animations, drag interactions, button press feel, feels janky, make it smooth.

baptisteArno/typebot.io스타 10,582(GitHub 10,582 + cccskills 0)

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • Choosing easing for a dropdown or modal
  • Tuning interaction timing and motion
  • Improving animation performance
  • Supporting reduced-motion preferences

포함된 파일(2)

  • SKILL.md10.7 KB
  • PRACTICAL-TIPS.md6.3 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Web Animation Design

A comprehensive guide for creating animations that feel right, based on Emil Kowalski's "Animations on the Web" course.

Initial Response

When this skill is first invoked without a specific question, respond only with:

I'm ready to help you with animations based on Emil Kowalski's animations.dev course.

Do not provide any other information until the user asks a question.

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:

BeforeAfter
transform: scale(0)transform: scale(0.95)
animation: fadeIn 400ms ease-inanimation: 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;
}

Timing and Duration

Duration Guidelines

Element TypeDuration
Micro-interactions100-150ms
Standard UI (tooltips, dropdowns)150-250ms
Modals, drawers200-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. See PRACTICAL-TIPS.md for detailed implementations.

ScenarioSolution
Make buttons feel responsiveAdd transform: scale(0.97) on :active
Element appears from nowhereStart from scale(0.95), not scale(0)
Shaky/jittery animationsAdd will-change: transform
Hover causes flickerAnimate child element, not parent
Popover scales from wrong pointSet transform-origin to trigger location
Sequential tooltips feel slowSkip delay/animation after first tooltip
Small buttons hard to tapUse 44px minimum hit area (pseudo-element)
Something still feels offAdd subtle blur (under 20px) to mask it
Hover triggers on mobileUse @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

Reference Files


리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

commit

무료

Choose one emoji prefix that reflects a change’s primary intent, then write concise commit messages or pull request titles. The skill also prompts a cleanup review before committing and explains how to preserve history after a PR is opened.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Writing a commit title with the required emoji prefix
  • Preparing a concise pull request title
  • Reviewing temporary files before committing
baptisteArno/typebot.io1.1만2026년 10월 26일 업데이트

ui

무료

Use this skill to build React frontend components that follow the project’s UI conventions. It guides layout choices, reuse of shared UI primitives, conditional Tailwind classes, prop ordering, and the organization of hooks, handlers, and derived values.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Building a new React component
  • Choosing layout and shared UI primitives
  • Organizing hooks and event handlers
baptisteArno/typebot.io1.1만2026년 10월 26일 업데이트

Use this skill to refresh the project’s available OpenAI and Anthropic model lists. It checks model IDs against models.dev, adds newer entries at the top while retaining older ones for compatibility, and updates image URL support patterns when needed.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Refreshing OpenAI model IDs
  • Updating Anthropic model lists
  • Checking image URL support patterns
baptisteArno/typebot.io1.1만2026년 10월 26일 업데이트

baptisteArno의 스킬 모두 보기

이 스킬의 문제 신고