Claude Code से उन्नत CSS एनीमेशन: प्रदर्शन, एक्सेसिबिलिटी और जांच

CSS एनीमेशन का लक्ष्य सिर्फ गति नहीं है

Claude Code से fade, slide या skeleton loader बनवाना आसान है। असली चुनौती तब आती है जब वही एनीमेशन production UI में जाता है। अच्छा एनीमेशन उपयोगकर्ता को बताता है कि क्या बदला है, पढ़ने में बाधा नहीं डालता, तेज रहता है, और उन लोगों की सेटिंग का सम्मान करता है जो कम motion पसंद करते हैं।

इस लेख में हम उन्नत CSS animation को implementation के नजरिए से देखेंगे। transition और keyframes का अंतर, transform और opacity को प्राथमिकता देने का कारण, layout thrash का अर्थ, prefers-reduced-motion, scroll-linked animation, entrance animation, skeleton state, design system tokens, Claude Code review prompt और Playwright visual checks सब शामिल हैं।

सरल शब्दों में: transition दो states के बीच smooth बदलाव है, जैसे hover पर button ऊपर जाना। keyframes समयरेखा है जिसमें 0%, 60%, 100% जैसे चरण होते हैं। layout thrash तब होता है जब browser बार-बार element की size और position फिर से calculate करता है। motion token ऐसा नामित value है जैसे --motion-duration-fast, जिससे duration, easing और distance consistent रहते हैं।

संबंधित पढ़ाई के लिए Claude Code performance optimization, Claude Code CSS variables और Claude Code accessibility देखें।

transition और keyframes को सोचकर चुनें

transition छोटे state changes के लिए बेहतर है: hover, focus, selected, expanded या disabled। keyframes तब उपयोगी हैं जब बीच का motion मायने रखता है: panel entrance, loading loop, staged notice, reading progress या scroll reveal।

Claude Code को prompt देते समय यह नियम साफ लिखें। अगर आप केवल “इसे animate करो” कहते हैं, तो generated CSS top, left, height या margin animate कर सकता है। ये properties layout recalculation करा सकती हैं और UI अटक सकता है।

:root {
  --motion-duration-fast: 160ms;
  --motion-duration-normal: 280ms;
  --motion-ease-standard: cubic-bezier(0.2, 0, 0, 1);
  --motion-distance-sm: 12px;
}

.button {
  transition:
    background-color var(--motion-duration-fast) var(--motion-ease-standard),
    transform var(--motion-duration-fast) var(--motion-ease-standard);
}

.button:hover {
  transform: translateY(-2px);
}

.notice {
  opacity: 0;
  transform: translateY(var(--motion-distance-sm));
  animation: notice-enter var(--motion-duration-normal) var(--motion-ease-standard) forwards;
}

@keyframes notice-enter {
  from {
    opacity: 0;
    transform: translateY(var(--motion-distance-sm));
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Button में transition है क्योंकि यह direct state change है। Notice में keyframes हैं क्योंकि इसका entrance planned है। Syntax के लिए MDN की CSS animations और transform documentation भरोसेमंद स्रोत हैं।

performance के लिए transform और opacity से शुरू करें

Browser एक frame बनाने के लिए layout, paint और composition करता है। layout size और position calculate करता है, paint pixels draw करता है, और composition layers को जोड़ता है। transform और opacity अक्सर composition stage में handle होते हैं, इसलिए वे smooth रहते हैं।

width, height, margin, top, left animate करने पर आसपास के elements प्रभावित हो सकते हैं। React component में animation class simple रखें ताकि Claude Code और tests दोनों आसानी से समझ सकें।

import type { ReactNode } from "react";
import "./motion.css";

type AnimatedPanelProps = {
  children: ReactNode;
  isOpen: boolean;
};

export function AnimatedPanel({ children, isOpen }: AnimatedPanelProps) {
  return (
    <section
      className={isOpen ? "panel panel-enter" : "panel"}
      aria-hidden={!isOpen}
    >
      {children}
    </section>
  );
}

.panel {
  opacity: 0;
  transform: translateY(12px) scale(0.98);
  pointer-events: none;
}

.panel-enter {
  animation: panel-enter 220ms cubic-bezier(0.2, 0, 0, 1) forwards;
  pointer-events: auto;
}

@keyframes panel-enter {
  to {
    opacity: 1;
    transform: translateY(0) scale(1);
  }
}

will-change को हर जगह मत लगाइए। animation शुरू होने से ठीक पहले सीमित रूप में उपयोग करें। web.dev की animation performance guide बताती है कि सही property चुनना सबसे बड़ा performance निर्णय है।

वास्तविक use cases

पहला use case card list, pricing panel या dashboard widget का entrance animation है। छोटा fade-up attention guide करता है। लेकिन हर card को लंबा delay देने से user पढ़ना देर से शुरू करता है। content animation fail होने पर भी visible रहना चाहिए।

दूसरा use case scroll-linked feedback है, जैसे reading progress bar या section reveal। animation-timeline अच्छा है, पर browser support अलग हो सकता है। इसलिए @supports fallback जरूरी है।

.scroll-progress {
  position: fixed;
  inset: 0 auto auto 0;
  z-index: 20;
  width: 100%;
  height: 3px;
  transform-origin: left;
  transform: scaleX(0);
  background: var(--color-accent, #2563eb);
}

@supports (animation-timeline: scroll()) {
  .scroll-progress {
    animation: progress-grow linear both;
    animation-timeline: scroll();
  }
}

@keyframes progress-grow {
  to {
    transform: scaleX(1);
  }
}

.reveal {
  opacity: 1;
  transform: none;
}

@supports (animation-timeline: view()) {
  .reveal {
    opacity: 0;
    transform: translateY(16px);
    animation: reveal-up 1ms linear both;
    animation-timeline: view();
    animation-range: entry 10% cover 30%;
  }
}

@keyframes reveal-up {
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

तीसरा use case skeleton loading है। Empty screen से बेहतर है कि user को loading shape दिखे, लेकिन तेज shimmer लंबे समय तक चले तो थकाने वाला लगता है। लंबी प्रक्रिया में status text, retry या cancel action भी दें।

चौथा use case SaaS dashboard feedback है: save complete, filter applied, item moved या error panel opened। यहाँ छोटी और शांत animation पर्याप्त है। रोज इस्तेमाल होने वाली screens में stability ज्यादा महत्वपूर्ण है।

reduced motion का सम्मान करें

prefers-reduced-motion user की कम motion preference पढ़ता है। यह accessibility का जरूरी हिस्सा है। कुछ users को तेज motion से असुविधा, dizziness या distraction हो सकता है। official reference MDN का prefers-reduced-motion है।

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

  .scroll-progress {
    animation: none;
    transform: scaleX(1);
  }

  .skeleton {
    animation: none;
    background-image: none;
  }
}

कुछ जगह animation नहीं करनी चाहिए: payment confirmation, legal text, critical form errors, लंबा reading content, dense data table और ऐसे menus जिन्हें user दिन में कई बार खोलता है। वहाँ clarity और immediate feedback बेहतर हैं।

Claude Code को reviewer की तरह prompt करें

सिर्फ “animation add करो” न कहें। risks check करने को कहें। यह prompt copy-paste किया जा सकता है:

Review and improve the CSS animation implementation for this UI.

Requirements:
- Use transition for simple hover/focus/open states.
- Use keyframes only when intermediate timing matters.
- Animate transform and opacity first; avoid top, left, width, height, and margin animations.
- Add design tokens for duration, easing, and distance.
- Respect prefers-reduced-motion.
- Keep content visible when scroll-linked animation is unsupported.
- Do not animate critical form errors, payment confirmation, or long reading content.

Return:
1. Risky selectors and why they are risky.
2. A corrected CSS/React implementation.
3. Manual and Playwright checks to verify overflow and reduced motion.

इससे Claude Code layout thrash, infinite loop, ज्यादा will-change, missing fallback और ignored motion preference जैसी गलतियां ढूंढेगा।

Playwright से visual checks करें

Animation bugs अक्सर visual होते हैं। horizontal overflow, visible content और reduced motion behavior के लिए focused Playwright checks जोड़ें।

import { expect, test } from "@playwright/test";

test("animated page has no horizontal overflow", async ({ page }) => {
  await page.goto("/animation-demo");
  const overflow = await page.evaluate(() => {
    return document.documentElement.scrollWidth > window.innerWidth;
  });
  expect(overflow).toBe(false);
});

test("reduced motion keeps content visible", async ({ browser }) => {
  const context = await browser.newContext({ reducedMotion: "reduce" });
  const page = await context.newPage();
  await page.goto("/animation-demo");

  await expect(page.locator(".reveal").first()).toBeVisible();
  await expect(page.locator(".skeleton").first()).toHaveCSS("animation-name", "none");

  await context.close();
});

Critical pages के लिए desktop और mobile screenshots भी compare करें। Tests design taste नहीं बताते, लेकिन hidden content, horizontal scroll और reduced motion ignore होने जैसी release problems पकड़ लेते हैं।

निष्कर्ष और अगला कदम

Production CSS animation साफ उद्देश्य से शुरू होती है। छोटे state changes के लिए transition, planned timeline के लिए keyframes, smooth motion के लिए transform और opacity, consistency के लिए tokens, accessibility के लिए reduced motion, और verification के लिए Playwright इस्तेमाल करें। Claude Code को ये constraints साफ मिलें तो output बेहतर होता है।

अगले कदम के रूप में किसी existing card list या CTA section पर इस लेख के tokens, entrance animation, reduced motion rule और Playwright checks लागू करें। अधिक गहरी implementation review के लिए training और consultation देखें।

व्यावहारिक verification note: examples को transform और opacity तक सीमित रखने पर horizontal overflow नहीं आया। Playwright reduced motion context में .reveal content visible रहा और skeleton animation बंद रही। लंबा shimmer operational screens में loading को और धीमा महसूस कराता है, इसलिए static placeholder बेहतर विकल्प निकला।