CSS-Architektur-Review

Das Problem

CSS waechst schneller als jede andere Sprache zu einem unwartbaren Sumpf. Entwickler ueberschreiben Spezifitaet mit !important statt die Kaskade zu korrigieren. Hardcodierte Pixelwerte und Hex-Farben verstreuen sich ueber Hunderte von Dateien. Das Ergebnis: ein Stylesheet, in dem niemand eine Regel zu loeschen wagt, und jedes neue Feature zunehmend bizarre Selektoren erfordert.

Der Prompt

Pruefe die folgende CSS-Architektur. Handle als Design-Systems-Engineer, der auf Skalierbarkeit, Konsistenz und Wartbarkeit bewertet.

METHODIK: [z.B. BEM, Tailwind, CSS Modules, styled-components, Vanilla CSS]
DESIGN SYSTEM: [z.B. Custom Tokens, Tailwind Config, Material UI Theme]

CSS/STYLE-CODE:
[Stylesheets, Komponentenstile oder Tailwind-Config einfuegen]

HTML/KOMPONENTEN-CODE (fuer Kontext):
[Relevantes Markup einfuegen]

Bewerte in diesen Dimensionen:

1. **Spezifitaetsmanagement**
   - Gibt es !important-Deklarationen? Warum?
   - Sind Selektoren angemessen flach (max 2-3 Ebenen)?
   - Werden IDs fuer Styling verwendet?
   - Ist die Kaskade vorhersehbar oder ein Spezifitaetskrieg?

2. **Design-Token-Compliance**
   - Verwenden Farben, Abstaende, Typografie und Schatten Tokens/Variablen?
   - Gibt es hardcodierte Hex-Werte, Pixelgroessen oder rohe rgba-Werte?
   - Kann das Theme allein durch Token-Wertaenderung gewechselt werden?

3. **Responsive-Strategie**
   - Wird Mobile-First-Ansatz verwendet (min-width Media Queries)?
   - Sind Breakpoints konsistent und nutzen Design Tokens?
   - Verwenden Layouts moderne Techniken (Grid, Flexbox), keine Floats?
   - Sind Touch-Targets mindestens 44x44px auf Mobile?

4. **Layout-Patterns**
   - Werden CSS Grid und Flexbox angemessen eingesetzt (Grid fuer 2D, Flex fuer 1D)?
   - Sind Layout-Utilities wiederverwendbar oder per Komponente copy-pasted?

5. **Performance**
   - Werden teure Selektoren vermieden (universal *, tiefe Nachfahren)?
   - Nutzen Animationen transform/opacity (GPU-beschleunigt)?

6. **Konsistenz**
   - Wird die Namenskonvention durchgaengig befolgt?
   - Gibt es toten/duplizierten CSS-Code?

Fuer jedes Problem liefere:
- **Ort**: Datei und Selektor
- **Schweregrad**: Kaputt (visueller Bug) / Schulden / Inkonsistent / Optimierung
- **Problem**: Was dieses CSS problematisch macht
- **Fix**: Korrigiertes CSS mit Erklaerung

Beispielausgabe

## CSS-Architektur-Review: 5 Probleme gefunden

### Schulden: Hardcodierte Farben ueberall
Ort: 23 Dateien enthalten rohe Hex-Werte wie #3b82f6, #1f2937
Fix: Tokens definieren und ersetzen:
  :root { --color-primary: #3b82f6; --color-text: #1f2937; }
  /* Vorher */ color: #3b82f6;
  /* Nachher */ color: var(--color-primary);

### Kaputt: Desktop-First Media Queries
Ort: src/styles/header.css
Fix: Auf Mobile-First umstellen:
  .nav { flex-direction: column; }
  @media (min-width: 768px) { .nav { flex-direction: row; } }

Wann verwenden

Beim Review von CSS-PRs, beim Aufbau eines Design Systems oder wenn Styles zunehmend schwer zu aendern sind. Unverzichtbar vor der Migration von Styling-Ansaetzen.

Profi-Tipps

• HTML-Struktur einbeziehen — CSS-Probleme stammen oft aus der HTML-Struktur. Eine Div-Suppe erzwingt komplexe Selektoren.
• Token-Extraktionsplan anfordern — “Extrahiere alle hardcodierten Werte in ein Design-Token-System mit Migrationsskript.”
• Scoped auditieren — bei grossen Projekten eine Seite oder Komponentengruppe nach der anderen reviewen.