CSS

CSS funktioniert über Selektoren (Auswähler) und Regeln.

/* Wähle alle Überschriften (h1) */
h1 {
  color: red;        /* Mach sie rot */
  font-size: 50px;   /* Mach sie riesig */
}

/* Wähle den Knopf mit der ID "login" */
#login {
  background: green; /* Grüner Hintergrund */
}

Du schreibst das meistens in eine eigene Datei (style.css), damit du das Design für alle Unterseiten nur an einer Stelle ändern musst.

1. Kaskade (Cascading)

Warum heißt es "Cascading"? Weil Regeln von oben nach unten "herabfließen" und sich überschreiben können. Regel 1: "Alle Texte sind schwarz." (Browser-Standard). Regel 2: "Alle Texte im Body sind grau." (Deine Datei). Regel 3: "Dieser spezielle Absatz ist pink." (Spezifität). Der Browser muss entscheiden, welche Regel gewinnt (Punktesystem für Wichtigkeit).

2. Flexbox & Grid

Früher hat man Layouts mit Tabellen gebaut (grauenhaft). Heute nutzt man Flexbox (für 1D-Reihen, z. B. Menüs) und Grid (für 2D-Raster, z. B. Fotogalerien). Das macht Webseiten responsiv (sie passen sich dem Handy-Bildschirm an).

1. Der Render Tree und Reflow Penalty

Wie macht der Browser aus CSS bunte Farbe?

1. Er parst HTML zum DOM (Document Object Model).
2. Er parst CSSOM (CSS Object Model).
3. Er verschmilzt beide zum verheerend komplexen Render Tree (nur, was physisch sichtbar ist). Wenn du per JavaScript im laufenden Betrieb element.style.width = '500px' änderst, zwingst du die gesamte Engine in einen Reflow (Layout berechnen) und Repaint (Farbe auf den Screen malen). Reflows kosten immens CPU-Kraft. Machst du das in einer Animation (Left: 1px, Left: 2px...), laggt das Smartphone. CSS-Profis nutzen stattdessen transform: translateX(50px), da dies auf den GPU-Layer (Grafikkarte) ausgelagert und nicht vom Haupt-Render-Tree neu kalkuliert wird.

2. Spezifitäts-Mathematik (The Specificity Wars)

Der furchtbarste Albtraum in 10-Jahre alten Codebases. Wenn zwei Anweisungen sich widersprechen, wer gewinnt? CSS kalkuliert das nicht chronologisch, sondern mathematisch durch Specificity Weights:

• 0, 0, 0, 1 (Tag) -> p {}
• 0, 0, 1, 0 (Class) -> .button {}
• 0, 1, 0, 0 (ID) -> #header {}
• 1, 0, 0, 0 (Inline) -> style="color:red" Ein Element mit ID #header schlägt erbarmungslos 1000 CSS-Klassen. Deswegen raten moderne Konzepte dazu, NIEMALS IDs (und erst recht kein !important) für CSS-Regeln zu nutzen, sondern das CSS flach auf Klassen-Ebene zu belassen (wie BEM: Block-Element-Modifier).

3. Präprozessoren und CSS-in-JS

Reines CSS hat als Sprache große strukturelle Defizite (früher keine Variablen, kein Nesting, grauenhaftes Code-Smell).

• SCSS / SASS: Ein Compiler vs. Interpreter (Präprozessor) liest .scss Dateien voller Variablen, Schleifen und if/else, und kompiliert (transpiliert) dies stumm ins saubere, aber dumme .css Artefakt für den Server.
• CSS-in-JS (Styled-Components / Emotion): Im React-Ökosystem verzichtet man oft völlig auf .css Dateien. Man injiziert CSS Strings direkt in die JavaScript-Komponenten-Baumstruktur. Der JavaScript-Bundler generiert zur Laufzeit unleserliche, kryptische Hashklassen (<div class="sc-axjAm">), die perfekt Encapsulation (Kapselung) (Kapselung) ohne Scope-Crossover garantieren.