Fortgeschrittene CSS-Animation mit Claude Code: schnell, zugänglich, testbar

CSS-Animation braucht Absicht, nicht nur Bewegung

Claude Code kann in wenigen Sekunden einen Fade, Slide oder Skeleton Loader schreiben. Schwieriger ist die Produktionsqualität: Die Animation muss erklären, was sich geändert hat, darf die Bedienung nicht bremsen, muss die Einstellung für weniger Bewegung respektieren und sollte in ein Designsystem passen.

Dieser Leitfaden betrachtet fortgeschrittene CSS-Animation aus Implementierungssicht. Es geht um transition vs. keyframes, warum transform und opacity meist die besten Animationsziele sind, was layout thrash bedeutet, wie prefers-reduced-motion eingebaut wird, wie Scroll- und Entrance-Animationen robust bleiben, wann Skeleton States sinnvoll sind, wie Motion Tokens helfen, wie Claude Code kritisch prüfen soll und wie Playwright visuelle Fehler findet.

Kurz erklärt: Eine transition verbindet zwei Zustände, etwa einen Hover-Zustand eines Buttons. Keyframes beschreiben eine Zeitachse mit Schritten wie 0%, 60% und 100%. Layout thrash entsteht, wenn der Browser Größen und Positionen wiederholt neu berechnen muss. Motion Tokens sind benannte Werte wie --motion-duration-fast, mit denen Dauer, Easing und Distanz konsistent bleiben.

Passende Vertiefungen sind Performance-Optimierung mit Claude Code, CSS-Variablen mit Claude Code und Barrierefreiheit mit Claude Code.

Transition und keyframes bewusst trennen

Transitions eignen sich für kleine Zustandswechsel: hover, focus, active, selected, expanded oder disabled. Keyframes sind sinnvoll, wenn Zwischenschritte wichtig sind: Panel-Eintritt, Ladeanimation, gestufte Hinweise, Lesefortschritt oder Reveal beim Scrollen.

Diese Entscheidung sollte im Prompt stehen. Wenn Sie nur “animieren” schreiben, kann generiertes CSS top, left, height oder margin animieren. Diese Eigenschaften können Layout-Neuberechnungen auslösen. Besser ist die Anweisung: transition für interaktive Zustände, keyframes für Zeitachsen, transform und opacity bevorzugen.

: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);
  }
}

Der Button nutzt transition, weil er direkt auf einen Zustand reagiert. Der Hinweis nutzt keyframes, weil sein Eintritt gestaltet ist. Für Syntax und Details sind MDN CSS animations und transform die offiziellen Referenzen.

Performance beginnt mit transform und opacity

Der Browser erzeugt ein Frame über Layout, Paint und Compositing. Layout berechnet Geometrie, Paint zeichnet Pixel, Compositing kombiniert Ebenen. transform und opacity bleiben häufig im Compositing und laufen deshalb stabiler als Geometrie-Änderungen.

width, height, margin, top und left können benachbarte Elemente beeinflussen. Wenn JavaScript zusätzlich Layoutwerte liest und danach Styles schreibt, entsteht layout thrash. In React sollte die Animationsklasse deshalb einfach und testbar bleiben.

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 sollte sparsam eingesetzt werden. Kurz vor einer Animation kann es helfen, dauerhaft auf vielen Elementen kostet es Speicher. Der web.dev-Leitfaden zu Animation Performance erklärt, warum die animierte Eigenschaft der wichtigste Hebel ist.

Reale Anwendungsfälle

Erster Fall: Entrance-Animationen für Karten, Preistabellen oder Dashboard-Module. Ein kurzer Eintritt lenkt den Blick. Eine lange Staffelung über alle Karten verzögert nur das Lesen. Die Inhalte müssen sichtbar bleiben, auch wenn die Animation nicht läuft.

Zweiter Fall: Scroll-Feedback, etwa eine Lesefortschrittsleiste oder ein Section Reveal. animation-timeline ist praktisch, braucht aber ein Fallback. Wenn der Browser die Funktion nicht unterstützt, darf der Inhalt nicht verschwinden.

.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);
  }
}

Dritter Fall: Skeleton- und Ladezustände. Ein Skeleton reduziert Unsicherheit, aber ein starkes Shimmer wirkt bei längeren Wartezeiten anstrengend. Für lange Vorgänge gehören Status, Wiederholen oder Abbrechen dazu.

Vierter Fall: Feedback in SaaS-Oberflächen. Gespeichert, Filter angewendet, Element verschoben oder Fehlerbereich geöffnet: Kurze Animation reicht. In Arbeitsoberflächen, die täglich benutzt werden, ist Ruhe wichtiger als Show.

Reduced motion respektieren und bewusst nicht animieren

prefers-reduced-motion liest die Nutzerpräferenz für weniger Bewegung. Das ist keine nette Ergänzung, sondern Teil zugänglicher UI. Starke Bewegung kann Beschwerden, Müdigkeit oder Ablenkung auslösen. Die offizielle MDN-Referenz zu prefers-reduced-motion zeigt die erwartete Nutzung.

@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;
  }
}

Manche Bereiche sollten gar nicht animiert werden: Zahlungsbestätigungen, Rechtstexte, kritische Formularfehler, lange Lesetexte, dichte Datentabellen und Menüs, die ständig geöffnet werden. Dort zählen Klarheit und sofortige Rückmeldung.

Claude Code als Reviewer einsetzen

Bitten Sie Claude Code nicht nur um Effekte, sondern um Risikoprüfung. Dieser Prompt ist direkt nutzbar:

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.

So sucht Claude Code nach layout thrash, Endlosschleifen, zu viel will-change, fehlenden Fallbacks und ignorierten Bewegungseinstellungen.

Mit Playwright visuell prüfen

Animationsfehler sind oft visuell. Ergänzen Sie gezielte Checks für horizontales Overflow, sichtbare Inhalte und reduced motion.

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();
});

Für kritische Seiten lohnt sich zusätzlich ein Screenshot-Vergleich auf Desktop und Mobil. Tests ersetzen kein Designurteil, aber sie finden versteckte Inhalte, horizontales Scrollen und ignorierte Bewegungseinstellungen früh.

Zusammenfassung und nächster Schritt

Produktionsreife CSS-Animation beginnt mit Absicht. Transition für kleine Zustände, keyframes für Zeitachsen, transform und opacity für flüssige Bewegung, Tokens für Konsistenz, reduced motion für Zugänglichkeit und Playwright als visuelle Sicherung. Claude Code liefert bessere Ergebnisse, wenn diese Grenzen klar sind.

Wählen Sie als nächsten Schritt eine vorhandene Kartenliste oder CTA-Sektion und wenden Sie Tokens, Entrance-Animation, reduced-motion-Regel und Playwright-Checks aus diesem Artikel an. Für einen tieferen Review-Prozess gibt es Training und Beratung.

Praktische Prüfung: Mit Animationen auf transform und opacity trat kein horizontales Overflow auf. In Playwright mit reduced motion blieb .reveal sichtbar und der Skeleton hatte keine Animation mehr. Ein langes Shimmer wirkte in Arbeitsoberflächen langsamer; ein ruhiger Platzhalter ist dort oft besser.