uni/slides/223015c/02-netzwerke-protokolle-css.md

---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: "Kapitel 2: Netzwerke, Protokolle & CSS"
---

<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #d63384;
  --color-dimmed: #4a4a6a;
}
section.invert { --color-foreground: #fff; }
section { font-size: 1.7rem; }
h1 { color: #a02060; }
section.invert h1 { color: #fff; }
h2 { color: #1f2937; }
pre {
  background: #0f0f23;
  color: #d63384;
  border-radius: 8px;
  border-left: 3px solid #d63384;
}
pre code { background: transparent; color: inherit; }
code {
  background: #0f0f23;
  padding: 0.15em 0.4em;
  border-radius: 4px;
  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
}
section code:not(.hljs) { color: #d63384 !important; }
section code.hljs { color: #f8f8f8 !important; }
a { color: var(--color-highlight); }
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #fce4ec,
    #fce4ec 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur { background: #fce4ec !important; }
}
section.aufgabe { background: #fce4ec !important; }
section.aufgabe footer { display: none; }
section.erklaerung { font-size: 1.1rem; }
section.erklaerung h1 { font-size: 1.5rem; color: #a02060; margin-bottom: 0.3rem; }
section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; }
section.erklaerung p { font-size: 1.0rem; line-height: 1.4; }
section.erklaerung table { font-size: 0.9rem; }
</style>

<!-- _class: lead -->

# Kapitel 2
## Netzwerke, Protokolle & CSS

<!--
Eine Stunde (oder zwei), eine Frage: *Wie reisen die Bytes vom Server in Frankfurt zu deinem Browser in Stuttgart — und wie wird ankommender HTML-Code zu einer hübschen barrierefreien Seite?*

Zwei Sub-Sektionen:
- Sub-A Netzwerk (25 Slides): IP/MAC/Port, TCP/IP-Schichten, DNS, HTTP, Synthese URL→Pixel
- Sub-B CSS + A11y (25 Slides): Anatomie, Selektoren, Box-Model, Flexbox/Grid, BFSG, WCAG POUR, semantisch + ARIA
-->

---

<!-- _class: lead -->

# Sub-Sektion A: Netzwerk
## Wie reisen Pakete?

<!--
Bogen Sub-A:
1. Drei Adressen (IP, MAC, Port)
2. TCP/IP-Schichtenmodell + Encapsulation
3. DNS (Adress-Lookup)
4. HTTP (Anfrage-Antwort)
5. TCP-Handshake
6. Synthese: URL → Pixel in 7 Schritten

Jede Folie bedient mindestens eines der Klausur-Lernziele C/D/E/F.
-->

---

<!-- _class: klausur -->

# Drei Adressen — IP · MAC · Port

| Adresse | Identifiziert | Beispiel |
|---------|---------------|----------|
| **IP** | das **Endgerät** (welt-eindeutig) | `192.168.1.42` (v4) · `2001:db8::1` (v6) |
| **MAC** | die **Netzwerk-Karte** (lokal eindeutig) | `00:1A:2B:3C:4D:5E` (6 Byte hex) |
| **Port** | das **Programm** auf dem Gerät | `80` (HTTP) · `443` (HTTPS) · `22` (SSH) |

**Drei Schichten, drei Fragen.** „Welcher Computer?" → IP. „Welches Kabel/WLAN?" → MAC. „Welches Programm?" → Port.

<!--
Klausurfähig (Block D).

Konkretes Beispiel:
- `localhost:8080` = IP 127.0.0.1 (eigene Maschine) + Port 8080 (typisch für lokale Dev-Server)
- `git.librete.ch:41240` = IP von librete.ch + Port 41240 (SSH-Custom-Port)
- `8.8.8.8:53` = Google's DNS-Server + Port 53 (DNS)

MAC ist die niedrigste Adress-Ebene — wird nur im lokalen Netz benutzt. Sobald ein Paket den Router verlässt, wird die MAC ausgetauscht (nächster Hop).
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/ip-packet.png)

<!--
IP-Adresse-Visualisierung.

Ein IP-Paket hat:
- Source-IP + Destination-IP (für Routing)
- Source-Port + Destination-Port (für Programm-Zuordnung beim Empfänger)
- Payload (die eigentlichen Daten der höheren Schicht)

IP v4 (32 Bit, 4 Dezimal-Zahlen): seit 1981. ~4,3 Milliarden Adressen, knapp geworden.
IP v6 (128 Bit, 8 hex-Gruppen): seit 1998. ~340 Sextillionen Adressen, mehr als nötig.
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/client-server-ports.png)

<!--
Port-Modell.

Ein Server kann **mehrere Dienste** gleichzeitig laufen lassen — jeder auf einem anderen Port:
- Port 80: HTTP
- Port 443: HTTPS
- Port 22: SSH
- Port 25: SMTP (Mail-Versand)
- Port 53: DNS

Der Client wählt einen zufälligen **Ephemeral Port** (49152–65535) für seine Antworten.

Im Browser tippt man die Port-Nummer nur explizit, wenn sie vom Standard abweicht (`localhost:8080` statt nur `localhost`).
-->

---

<!-- _class: lead -->

# TCP/IP-Schichtenmodell

<!--
Übergang: Adressen verstehen. Jetzt: wie sind diese Adressen organisiert?

Antwort: in vier Schichten. Jede Schicht hat ihre Aufgabe und ihre Adressen.
-->

---

# Warum Schichten?

Komplexes Problem **„Daten von A nach B"** in kleine Aufgaben **zerlegt:**

- Welche elektrischen Signale auf dem Kabel? (Schicht 1)
- Wie ist das Paket adressiert? (Schicht 2)
- Wie kommt das Paket über mehrere Hops? (Schicht 3)
- Wie ist die Verbindung zuverlässig? (Schicht 4)
- Welche Anwendung benutzt das? (Schicht 5)

**Jede Schicht ignoriert, was die anderen tun.** Modularer, austauschbarer, debugbarer.

<!--
Schichten-Konzept ist eine fundamentale Idee in der Informatik (auch in Architektur, Mathematik, Wissenschaft).

Vorteil:
- Jede Schicht hat klare Schnittstelle nach oben/unten
- Eine Schicht kann ausgetauscht werden, ohne die anderen zu betreffen (z.B. WLAN statt Ethernet → Schicht 1+2, nicht 3+4+5)
- Fehler werden auf einer Schicht eingegrenzt

Beispiel-Anwendung im Studi-Alltag: WLAN-Probleme. Wenn Browser keine Seite öffnet, fragt man:
- Ist WLAN verbunden? (Schicht 1+2)
- Hat das Gerät eine IP? (Schicht 3)
- Erreicht ein Ping den Router? (Schicht 3)
- Erreicht der DNS einen Server? (Schicht 5+)

Pro Antwort weiter unten ist der Fehler eingegrenzt.
-->

---

<!-- _class: klausur -->

# TCP/IP · 4 Schichten

| # | Schicht | Aufgabe | Beispiel-Protokolle | Dateneinheit |
|---|---------|---------|---------------------|--------------|
| 1 | **Network Access** | Bits auf Kabel/WLAN | Ethernet · WiFi | Frame |
| 2 | **Internet** | Routing über mehrere Hops | **IP** · ICMP | Packet |
| 3 | **Transport** | Verbindung + Zuverlässigkeit | **TCP** · UDP | Segment |
| 4 | **Application** | Anwendungs-Logik | **HTTP** · DNS · SMTP | Data |

Schichten von unten nach oben. Jede höhere Schicht **nutzt** die darunter.

<!--
Klausurfähig (Block C). Studis sollen die 4 Schichten benennen + ein Protokoll pro Schicht zuordnen + die Dateneinheit pro Schicht.

Wichtige Protokolle:
- Schicht 1: Ethernet (Kabel), WiFi 802.11 (Funk), Bluetooth
- Schicht 2: IP v4/v6, ICMP (Ping), ARP (IP→MAC-Auflösung)
- Schicht 3: TCP (zuverlässig, mit Handshake), UDP (schnell, ohne Garantien)
- Schicht 4: HTTP/HTTPS, DNS, SMTP/IMAP/POP3, SSH, FTP, MQTT

Faustregel: jeder Buchstabe in einem URL-Schema sagt was über Schicht 4 (HTTP, FTP, MQTT, …).
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/encap-stack.png)

<!--
Encapsulation: jede höhere Schicht wird in einen Umschlag der nächsttieferen Schicht gepackt.

- Schicht 4 (Anwendung): "Hallo, das ist meine HTTP-Anfrage"
- Schicht 3 (Transport): Schicht-4-Daten + TCP-Header → Segment
- Schicht 2 (Internet): Segment + IP-Header → Packet
- Schicht 1 (Link): Packet + Ethernet-Header → Frame

Sender packt von oben nach unten ein. Empfänger packt von unten nach oben aus.

Sehr wichtig: jede Schicht sieht nur ihren eigenen Header — sie kann den Inhalt der höheren Schichten ignorieren. Das ist die Modularität.
-->

---

<!-- _class: klausur -->

# Encapsulation — Datenüberbringung

```
[Application Data]
        ↓ + TCP-Header
[Segment]
        ↓ + IP-Header
[Packet]
        ↓ + Ethernet-Header + Trailer
[Frame]
        ↓ als Bits auf das Kabel/WLAN
```

Beim Empfänger: **umgekehrte Reihenfolge.**

<!--
Klausurfähig (Block C.2, C.3).

Diese Verschachtelung ist nicht zufällig — sie ist die direkte Folge der Schichten-Architektur. Jede Schicht braucht eigene Adressierung + eigene Kontrolldaten → eigener Header.

Konsequenz: ein HTTP-Request hat in der Realität wesentlich mehr „Overhead" als nur die HTTP-Daten:
- Ethernet-Header: 14 Byte
- IP-Header: 20 Byte (v4) oder 40 Byte (v6)
- TCP-Header: 20 Byte (oft mit Optionen mehr)
- + HTTP-Header: typisch 200-1000 Byte
- Bei kleinem HTTP-Body: Overhead > Payload
-->

---

# OSI vs TCP/IP

| OSI (7 Schichten) | TCP/IP (4 Schichten) |
|-------------------|----------------------|
| 7 Application | Application |
| 6 Presentation | (in App-Schicht) |
| 5 Session | (in App-Schicht) |
| 4 Transport | Transport |
| 3 Network | Internet |
| 2 Data Link | Network Access |
| 1 Physical | (in Network Access) |

**OSI:** theoretisches Lehrbuch-Modell (ISO, 1984).
**TCP/IP:** das Modell, das in der Praxis verwendet wird.

<!--
Klausurfähig (Block C.4): die zwei Modelle nebeneinander stellen können.

OSI hat 7 Schichten. Die obersten drei (Application, Presentation, Session) wurden in der TCP/IP-Welt nicht so streng getrennt — die gesamte Anwendungs-Logik wird in EINER Schicht (Application) zusammengefasst.

OSI wird heute selten als Modell verwendet — TCP/IP hat sich durchgesetzt. Aber für die Klausur wichtig: beide kennen, vergleichen können.
-->

---

<!-- _class: lead -->

# DNS — die Adress-Auskunft

<!--
Bisher: Adressen sind IP-Nummern. Aber Menschen tippen `librete.ch`, nicht `185.232.71.45`.

DNS ist das System, das URL-Namen in IP-Adressen übersetzt.
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/dns-lookup.png)

<!--
Ein DNS-Lookup hat mehrere Schritte:

1. Browser fragt den **DNS-Resolver** (meist beim ISP konfiguriert, z.B. 1.1.1.1 von Cloudflare)
2. Resolver fragt einen der **Root-Server** (13 weltweit, .root)
3. Root antwortet: „kenne ich nicht, frag den .ch-TLD-Server"
4. Resolver fragt den **TLD-Server** für .ch
5. TLD antwortet: „kenne ich nicht, frag den autoritativen Server für librete.ch"
6. Resolver fragt den **autoritativen Nameserver** (oft beim Hoster)
7. Authoritative antwortet: „librete.ch ist 185.232.71.45"
8. Resolver liefert die IP zurück an den Browser

Beim nächsten Mal: viele Schritte gecacht — Antwort kommt in Millisekunden.
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/dns-tree.png)

<!--
DNS ist hierarchisch organisiert wie ein umgekehrter Baum:

Root (.)
  ├── .com (TLD)
  │     ├── google.com
  │     └── ...
  ├── .ch (TLD)
  │     ├── librete.ch
  │     └── admin.ch
  ├── .de
  │     ├── hdm-stuttgart.de
  │     └── ...
  └── .org

Jede Ebene ist eine separate Authoritative-Zone. Wer eine .ch-Domain registriert, kommt ins Register von SWITCH (Schweizer Registry).

Wichtige Records:
- A: IPv4-Adresse
- AAAA: IPv6-Adresse
- MX: Mail-Server
- CNAME: Alias auf anderen Namen
- TXT: freier Text (oft für SPF, DKIM, Domain-Verifikation)
-->

---

<!-- _class: lead -->

# HTTP — die Sprache des Webs

<!--
Bisher: wir wissen, wie eine TCP-Verbindung aufgebaut wird, wie DNS funktioniert, wie eine IP-Adresse gefunden wird.

Jetzt: was geht ÜBER die Verbindung? Bei einer Webseite: HTTP-Requests.
-->

---

<!-- _class: klausur -->

# HTTP-Request — was geschickt wird

```http
GET /index.html HTTP/1.1
Host: librete.ch
User-Agent: Mozilla/5.0 (Macintosh; …)
Accept: text/html,application/xhtml+xml
Accept-Language: de-DE,en-US;q=0.9
Connection: keep-alive
```

| Bestandteil | Was |
|-------------|-----|
| `GET` | **Method** — was tun wir |
| `/index.html` | **Path** — was wollen wir |
| `HTTP/1.1` | **Version** |
| `Host: …` | **Header** (mehrere möglich) |

<!--
Klausurfähig (Block E.2). Studis sollen einen HTTP-Request lesen können.

Wichtige Methods:
- GET: lesen (idempotent — gleiche Anfrage gibt gleiche Antwort)
- POST: erstellen / Daten senden
- PUT: ersetzen
- DELETE: löschen
- HEAD: nur Header holen (z.B. um Datei-Größe zu prüfen ohne Download)

Wichtige Header:
- Host: welche Website auf dem Server (mehrere Sites pro Server möglich)
- User-Agent: Browser-Identifikation
- Accept: welche Content-Types die App verarbeiten kann
- Cookie: Session-Identifikation
- Authorization: Login-Token
-->

---

<!-- _class: klausur -->

# HTTP-Response — was zurückkommt

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Cache-Control: max-age=3600
Server: nginx/1.24

<!DOCTYPE html>
<html>...
```

| Bestandteil | Was |
|-------------|-----|
| `200 OK` | **Statuscode + Message** |
| `Content-Type: …` | **Header** mit Meta-Information |
| (leere Zeile) | trennt Header von Body |
| `<!DOCTYPE …` | **Body** (eigentlicher Inhalt) |

<!--
Klausurfähig (Block E.2).

Status-Code ist die wichtigste Zeile. Drei Stellen, erste Stelle gibt grobe Kategorie:
- 1xx: Informational (Hinweise)
- 2xx: Success (alles ok)
- 3xx: Redirect (woanders gucken)
- 4xx: Client Error (du hast Mist gebaut)
- 5xx: Server Error (Server hat Mist gebaut)
-->

---

<!-- _class: klausur -->

# Statuscodes — die wichtigsten

| Code | Name | Bedeutung |
|------|------|-----------|
| **200** | OK | alles gut, hier dein Inhalt |
| **301** | Moved Permanently | Seite ist umgezogen, hier neue URL |
| **302** | Found | temporäre Weiterleitung |
| **400** | Bad Request | deine Anfrage war kaputt |
| **401** | Unauthorized | du musst dich einloggen |
| **403** | Forbidden | eingeloggt aber nicht berechtigt |
| **404** | Not Found | gibt's nicht |
| **500** | Internal Server Error | Server hat Bug |
| **503** | Service Unavailable | Server überlastet / down |

<!--
Klausurfähig (Block E.3): mindestens 200, 301, 404, 500 mit Bedeutung.

Memo:
- 200 = "OK" — alltäglich erfolgreich
- 301 = permanenter Umzug (Cache-fähig, SEO-Geschichte)
- 404 = klassisch — Endbenutzer kennt sie
- 500 = Server crasht
-->

---

# HTTP/1.1 → HTTP/2 → HTTP/3

| Version | Jahr | Hauptverbesserung |
|---------|------|-------------------|
| HTTP/1.0 | 1996 | erste Spec |
| **HTTP/1.1** | 1997 | persistent connections (1 TCP für viele Requests) |
| **HTTP/2** | 2015 | multiplexing (parallele Streams im selben TCP) + Header-Komprimierung |
| **HTTP/3** | 2022 | basiert auf **QUIC** (UDP statt TCP), schnellere Handshakes |

Heute: HTTP/2 dominant. HTTP/3 wächst stark, besonders bei Google, Cloudflare.

<!--
Klausurfähig (Block E.4): die drei Versionen unterscheiden können.

HTTP/1.1: 1 TCP-Verbindung, Requests sequentiell. „Head-of-Line Blocking" — langsame Antwort blockiert nächste Requests.

HTTP/2:
- 1 TCP-Verbindung, viele parallele Streams (Multiplexing)
- Header werden komprimiert (HPACK)
- Server kann zusätzliche Resources mit dem ersten Response „pushen"
- Schneller, weniger Latenz

HTTP/3:
- statt TCP ein neues Protokoll namens QUIC (basiert auf UDP)
- TLS direkt integriert (kein separater Handshake mehr)
- Schnellere Verbindungs-Wiederherstellung bei WLAN-Wechsel
- Heute Standard bei Google-Services
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/tcp-handshake.png)

<!--
TCP-Handshake (3-Wege-Handshake):

1. Client → Server: SYN (synchronize) "Hallo, ich möchte verbinden, hier ist meine Initial-Sequence-Number"
2. Server → Client: SYN-ACK "Hallo zurück, hier ist meine Initial-Sequence-Number"
3. Client → Server: ACK "Verstanden, Verbindung steht"

Erst nach dem 3-Wege-Handshake können Daten fließen.

Warum 3 Wege? Weil beide Seiten sich auf eine gemeinsame Sequence-Number einigen müssen, mit der die einzelnen Bytes durchnummeriert werden — für zuverlässige Übertragung.

UDP hingegen hat keinen Handshake — Pakete fliegen los ohne Bestätigung. Schneller, aber unsicher.
-->

---

<!-- _class: klausur -->

# Block F · URL → Pixel in 7 Schritten

1. **URL parsen** — Schema, Host, Port, Path extrahieren
2. **DNS-Lookup** — Host-Name → IP-Adresse
3. **TCP-Handshake** mit Server-IP auf Port 443
4. **TLS-Handshake** für https (Zertifikat prüfen)
5. **HTTP-Request** senden
6. Server antwortet mit **HTML, CSS, JS** (als Body)
7. Browser **parsed + rendert** — HTML-Baum + CSS-Regeln + JS-Ausführung → Pixel

<!--
Klausurfähig (Block F — die Synthese-Stelle).

Pädagogisch wichtig: Studis sollen diese 7 Schritte FREI reproduzieren können.

Konkretes Beispiel: was passiert, wenn ich `https://librete.ch` eintippe?
1. URL: Schema https, Host librete.ch, Port 443 (Default für https), Path /
2. DNS-Resolver fragt: librete.ch → 185.232.71.45
3. Browser öffnet TCP-Verbindung zu 185.232.71.45:443
4. TLS-Handshake: Zertifikat prüfen, Verschlüsselung aushandeln
5. HTTP-Request: `GET / HTTP/1.1 \r\n Host: librete.ch ...`
6. Server antwortet mit `HTTP/1.1 200 OK` + HTML
7. Browser baut DOM-Tree, lädt CSS-Dateien, lädt Bilder, führt JS aus, rendert Pixel
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/network-chain.png)

<!--
Visualisierung des kompletten Ablaufs als Pipeline. Jede Box = ein Schritt.

In der Vorlesung an dieser Folie länger verweilen, alle Stationen ablaufen.

Vor allem für die Klausur einprägen: 7 Schritte, Reihenfolge wichtig.
-->

---

<!-- _class: lead -->

# Sub-Sektion B: CSS + A11y
## Wie wird HTML hübsch + barrierefrei?

<!--
Pivot. Wir haben gesehen, wie Bytes reisen. Jetzt: was passiert nach dem Schritt 6 (Browser empfängt HTML)?

Antwort: HTML kommt mit CSS-Links → Browser lädt CSS → wendet Styles an → rendert Pixel.

Plus: für Studierende heute Pflicht — Accessibility (BFSG).
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/css-anatomie.png)

<!--
CSS-Anatomie:

```css
selector {
  property: value;
}
```

Beispiel:
```css
button {
  background-color: hotpink;
  padding: 10px 20px;
}
```

`button` = Selektor (welche Elemente betroffen)
`background-color`, `padding` = Properties (welche Eigenschaft)
`hotpink`, `10px 20px` = Values (welcher Wert)

Drei Stellen, an denen CSS im HTML eingebunden wird:
1. `<link rel="stylesheet" href="style.css">` im head (External)
2. `<style>...</style>` im head (Internal)
3. `<button style="...">` direkt am Element (Inline — vermeiden)

Standard: External in style.css.
-->

---

<!-- _class: klausur -->

# CSS-Selektoren

| Selektor | Was |
|----------|-----|
| `p` | alle `<p>`-Elemente |
| `.btn` | alle Elemente mit `class="btn"` |
| `#header` | das Element mit `id="header"` (nur EINS pro Seite) |
| `*` | alle Elemente |
| `button:hover` | Button beim Hover |
| `button:focus` | Button mit Tastatur-Fokus |
| `input:disabled` | deaktivierte Inputs |
| `nav > a` | alle `<a>` direkt unter `<nav>` |
| `h1 + p` | erstes `<p>` direkt nach einem `<h1>` |

<!--
Klausurfähig (Block H.2).

Grundtypen:
- Element-Selektor: `p`
- Klassen-Selektor: `.btn` (kann mehrfach vorkommen)
- ID-Selektor: `#header` (einmalig pro Seite!)
- Universal-Selektor: `*`

Pseudo-Klassen (Element in einem bestimmten Zustand):
- :hover, :focus, :active
- :first-child, :last-child, :nth-child(2n)
- :disabled, :checked, :required

Kombinatoren:
- a > b: b ist direktes Kind von a
- a b: b ist irgendwo unter a (Descendant)
- a + b: b ist direkter Geschwister-NACHFOLGER von a
- a ~ b: b ist Geschwister von a (irgendwo nach)
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/css-combinators.png)

<!--
Visualisierung der Kombinatoren.

Pädagogisch: zeigen, dass die Wahl des Kombinators bestimmt, WELCHE Elemente getroffen werden — auch wenn sie alle den gleichen Namen haben.

Faustregel: nur so spezifisch wie nötig. „nav > a" ist klar (Links in Hauptnavigation). „div ul li a:hover" ist zu verschachtelt — bricht beim ersten HTML-Refactor.
-->

---

<!-- _class: klausur -->

# Spezifizität — wer gewinnt?

Wenn mehrere CSS-Regeln auf das gleiche Element zutreffen: **die spezifischste gewinnt.**

| Selektor-Typ | Spezifizität |
|--------------|-------------:|
| Inline `style="..."` | 1000 |
| ID `#header` | 100 |
| Klasse `.btn`, Attribut `[type=text]`, Pseudo `:hover` | 10 |
| Element `p`, Pseudo-Element `::before` | 1 |
| `*` | 0 |

Bei Gleichstand: **letzte Regel** im CSS gewinnt.

<!--
Klausurfähig (Block H.3).

Konkretes Beispiel:
```css
p { color: blue; }           /* Spezifizität: 1 */
.notice { color: red; }      /* Spezifizität: 10 */
#warn { color: green; }      /* Spezifizität: 100 */
```

Wenn ein `<p id="warn" class="notice">Hi</p>` definiert ist:
- Welche Farbe? Grün, weil #warn (100) > .notice (10) > p (1).

`!important` umgeht die Regel — sollte vermieden werden (macht Refactoring schwer).
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/css-box-model.png)

<!--
Box-Model: jedes Element ist eine Box.

Von innen nach außen:
1. Content: der eigentliche Inhalt
2. Padding: Innenabstand zwischen Inhalt und Border
3. Border: Rahmen
4. Margin: Außenabstand zu anderen Elementen

Beispiel:
```css
button {
  width: 200px;
  padding: 10px;
  border: 2px solid;
  margin: 20px;
}
```

Default `box-sizing: content-box`: width=200 bezieht sich nur auf Content, Gesamt-Breite wäre 200+10+10+2+2 = 224 px.

Mit `box-sizing: border-box`: width=200 inkludiert Padding+Border, Gesamt-Breite ist 200 px.

Heute Best-Practice: `* { box-sizing: border-box; }` global setzen.
-->

---

<!-- _class: klausur -->

# Box-Model

```
+------------------------+
|        margin          |
|  +------------------+  |
|  |     border       |  |
|  | +--------------+ |  |
|  | |   padding    | |  |
|  | | +----------+ | |  |
|  | | | content  | | |  |
|  | | +----------+ | |  |
|  | +--------------+ |  |
|  +------------------+  |
+------------------------+
```

`box-sizing: border-box;` ist Best Practice — `width` inkludiert dann Padding + Border.

<!--
Klausurfähig (Block H.1).

Studis sollen das Box-Model malen können + erklären, was content/padding/border/margin ist + Bedeutung von `box-sizing: border-box`.

Tip: in DevTools, beim Inspector wird die Box-Model-Visualisierung neben dem Element angezeigt — beste Lern-Methode.
-->

---

# Display: block · inline · flex · grid

| Display | Was |
|---------|-----|
| `block` | nimmt die volle Breite, untereinander |
| `inline` | nur so breit wie nötig, nebeneinander |
| `inline-block` | nebeneinander, aber width/height respektieren |
| **`flex`** | 1D-Layout (Reihe oder Spalte) |
| **`grid`** | 2D-Layout (Raster) |
| `none` | nicht angezeigt |

**Flex und Grid sind die modernen Layout-Werkzeuge.**

<!--
Lange Geschichte:
- Bis HTML4: Tabellen-Layouts (`<table>` für Seitenstruktur)
- Bis CSS3: `float` für Spalten-Layouts
- 2012+: Flexbox für 1D-Layouts
- 2017+: Grid für 2D-Layouts

Heute: Flexbox für Listen, Buttons, Karten-Reihen. Grid für ganze Seiten-Layouts, komplexe Gitter.

Klausur (H.4): Flexbox vs Grid unterscheiden — wann was?
-->

---

<!-- _class: klausur -->

# Flexbox vs Grid

| | Flexbox | Grid |
|--|---------|------|
| Dimensions | **1D** (Reihe ODER Spalte) | **2D** (Reihe UND Spalte) |
| Geeignet für | Navigation, Karten-Liste, Button-Gruppe | Seiten-Layout, komplexe Raster |
| Container-CSS | `display: flex` | `display: grid` |
| Reihen-Richtung | `flex-direction` | `grid-template-rows` |
| Spalten-Richtung | (durch flex-direction) | `grid-template-columns` |

**Faustregel:** Brauchst du nur eine Richtung? Flex. Beide? Grid.

<!--
Klausurfähig (Block H.4 konzeptionell, nicht Code).

Konkrete Beispiele:
- Header-Navigation mit Logo links + Links rechts → Flexbox (1D Horizontal)
- Foto-Galerie mit gleichmäßigen Karten → Grid (2D, fixe Spalten)
- Sidebar + Hauptinhalt + Footer-Layout → Grid (ganze Seite)
- Button mit Icon links + Text rechts → Flexbox
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/css-responsive.png)

<!--
Responsive Design = Layout passt sich an unterschiedliche Bildschirm-Größen an.

Media Queries:
```css
/* Mobile-first: Default für klein */
.sidebar { display: none; }

/* Tablet aufwärts: Sidebar einblenden */
@media (min-width: 768px) {
  .sidebar { display: block; width: 240px; }
}

/* Desktop: noch breiter */
@media (min-width: 1280px) {
  .sidebar { width: 320px; }
}
```

Wichtig: `<meta name="viewport" content="width=device-width">` im head, sonst zoomt Mobile.

Faustregel: Mobile-first denken → Styles erst für klein, dann für größer ergänzen.
-->

---

<!-- _class: lead -->

# Barrierefreiheit — Pflicht seit 28.06.2025

<!--
Der wichtigste Block in 2026: A11y.

Hintergrund:
- BFSG (Barrierefreiheitsstärkungsgesetz) — Deutsches Gesetz
- EAA (European Accessibility Act) — EU-Richtlinie
- Beide treten am 28.06.2025 in Kraft
- Digitale Produkte müssen barrierefrei sein

Für Studis besonders relevant:
- Ihr werdet in der Praxis Websites bauen, die der gesetzlichen Pflicht unterliegen
- Verstoß kann zu Geldbußen + Reputationsschaden führen
- Best-Practice baut Barrierefreiheit gleich ein, nicht am Ende
-->

---

<!-- _class: klausur -->

# BFSG + EAA — was kommt am 28.06.2025?

**Barrierefreiheitsstärkungsgesetz (BFSG)** — DE-Gesetz, setzt **European Accessibility Act (EAA)** um.

**Pflicht für:**
- Online-Shops, Buchungssysteme
- Banken, Versicherungen
- E-Books, E-Reader
- Smartphone-Apps mit kommerziellem Bezug

**Ausnahmen:** Unternehmen < 10 Mitarbeiter + < 2 Mio € Umsatz.

Verstöße: bis **100 000 €** Bußgeld + Klagerecht durch Behindertenverbände.

<!--
Klausurfähig (Block I.1). Studis sollen kennen:
- BFSG / EAA als Gesetz/Richtlinie
- Datum 28.06.2025
- Wer betroffen ist
- Strafrahmen

Hintergrund: ~10% der Bevölkerung haben relevante Behinderungen (Sehen, Hören, Motorik, kognitiv). Die meisten Websites sind nicht barrierefrei → diese Menschen werden ausgeschlossen.

EU hat das mit EAA 2019 beschlossen. DE setzt es mit BFSG 2021 in nationales Recht. Übergangsfrist endet 28.06.2025.
-->

---

<!-- _class: klausur -->

# WCAG · 4 Prinzipien (POUR)

| Prinzip | Bedeutung | Beispiel |
|---------|-----------|----------|
| **P**erceivable | wahrnehmbar | Alt-Text für Bilder, Untertitel für Video |
| **O**perable | bedienbar | Keyboard-Navigation, Skip-Links |
| **U**nderstandable | verständlich | Lese-Niveau, klare Fehlermeldungen |
| **R**obust | robust gegenüber Tech | semantisches HTML, Standards-konform |

**WCAG 2.1 Level AA** ist meist Mindest-Anforderung.

<!--
Klausurfähig (Block I.2). Die 4 POUR-Prinzipien benennen können.

WCAG = Web Content Accessibility Guidelines, vom W3C.
- WCAG 1.0 (1999), 2.0 (2008), 2.1 (2018), 2.2 (2023)
- Drei Stufen: A (Minimum), AA (Standard), AAA (höchste)
- BFSG verlangt Level AA

Konkrete WCAG-Kriterien (Beispiele):
- 1.1.1 Non-text Content: Alt-Text für alle Bilder
- 1.4.3 Contrast (Minimum): Kontrast 4.5:1 für Text
- 2.1.1 Keyboard: alle Funktionen mit Tastatur erreichbar
- 2.4.7 Focus Visible: Fokus-Indikator sichtbar
- 3.3.1 Error Identification: Fehler klar markieren
- 4.1.2 Name, Role, Value: ARIA korrekt einsetzen
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/a11y-semantic.png)

<!--
Semantisches HTML ist die GRUNDLAGE von A11y.

Vergleich:
- `<div onclick="...">Klick mich</div>` → keyboard nicht erreichbar, Screen-Reader kann es nicht als Button erkennen
- `<button onclick="...">Klick mich</button>` → automatisch keyboard-erreichbar (Tab + Enter), Screen-Reader sagt „Button: Klick mich"

Faustregel: WENN es einen passenden HTML-Tag gibt, NIMM den. ARIA-Attribute nur ergänzend, nicht als Ersatz.
-->

---

# ARIA — nur als Ergänzung

```html
<!-- Schlecht: div mit ARIA-Krücken -->
<div role="button" tabindex="0" onclick="...">Klick</div>

<!-- Gut: nativer Button -->
<button onclick="...">Klick</button>

<!-- ARIA OK wenn HTML nicht reicht -->
<nav aria-label="Hauptnavigation">
  <a href="...">Home</a>
</nav>
```

**Erste Regel von ARIA:** *keine ARIA-Attribute verwenden, wenn das richtige HTML-Element verfügbar ist.*

<!--
ARIA (Accessible Rich Internet Applications) = Erweiterung der HTML-Semantik für Screen-Reader.

Wichtige Attribute:
- `role="..."`: was tut dieses Element
- `aria-label="..."`: Beschreibung für Screen-Reader
- `aria-hidden="true"`: vor Screen-Reader verstecken
- `aria-live="polite"`: dynamische Updates ankündigen

Wann ARIA?
- Wenn HTML keine passende Semantik bietet (z.B. Custom Dropdown, Tabs, Carousel)
- Wenn dynamische Updates passieren (z.B. Live-Suchergebnisse)

Wann KEIN ARIA?
- Wenn `<button>` möglich → `<button>` nehmen, nicht `<div role="button">`
- Wenn `<nav>` möglich → `<nav>` nehmen, nicht `<div role="navigation">`
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/contrast-levels.png)

<!--
Kontrast-Anforderung (WCAG):
- Level AA: Text-Kontrast mindestens 4.5:1
- Level AA: große Texte (>=18pt oder >=14pt fett): 3:1
- Level AAA: höhere Anforderungen (7:1 für Text)

Wie messen?
- Browser-DevTools (manche zeigen Kontrast direkt im Inspector)
- Online-Tools: webaim.org/resources/contrastchecker
- Figma, Sketch haben Plugins

Häufiger Fehler: graues Lesetext auf weißem Hintergrund. Sieht „elegant" aus, ist aber bei #777 auf #fff unter 4.5 — schlecht lesbar.

Tipp: hauptsächlich schwarzer Text auf hellem Hintergrund (oder umgekehrt). Erst von dort weicht man bewusst ab.
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/keyboard-a11y.png)

<!--
Keyboard-Navigation:

Alle interaktiven Elemente müssen mit Tastatur erreichbar sein:
- Tab: nächstes interaktives Element
- Shift+Tab: vorheriges
- Enter / Space: aktivieren
- Pfeiltasten: in Listen, Tabs, Radios

Wer das nicht testet: einfach Maus weglegen und nur mit Tab durch die eigene Webseite klicken. Wo bleibt der Fokus stecken? Wo ist nicht klar, wo der Fokus liegt?

Häufige Fehler:
- `:focus { outline: none; }` ohne Ersatz → Fokus unsichtbar
- `<div onclick>` ohne tabindex=0 + Enter-Handler → nicht erreichbar
- Custom-Components ohne Keyboard-Support

CSS-Best-Practice: `:focus-visible` statt `:focus` — zeigt Outline nur bei Tastatur-Navigation, nicht bei Maus-Klick.
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/a11y-error.png)

<!--
Fehler-States müssen klar markiert sein:
- **Visuell:** rote Border, Icon
- **Textuell:** Erklärung was falsch ist, wie man's korrigiert
- **ARIA:** `aria-invalid="true"` + `aria-describedby="error-id"` für Screen-Reader

Anti-Pattern:
- Nur rote Border ohne Text → Farbblinde haben keine Chance
- Generische Fehlermeldung „Eingabe ungültig" → User weiß nicht, was zu korrigieren ist

Best-Practice:
- Konkret: "E-Mail muss ein @-Zeichen enthalten"
- Hilfreich: "Versuche format: name@beispiel.de"
- Lokalisiert beim fehlerhaften Feld
-->

---

<!-- _class: aufgabe -->

# Selbstlernen — A11y-Audit am eigenen Projekt

1. Öffnet eine eigene Seite (oder eure HdM-Übungsseite)
2. **Lighthouse** in Chrome DevTools öffnen
3. Audit „Accessibility" laufen lassen
4. Schaut die Top-3-Probleme an → was bedeuten sie?

**Manuell:**
5. Maus weglegen — nur mit **Tab** durchnavigieren. Wo bleibt der Fokus stecken?
6. Zoomt im Browser auf 200% — bleibt die Seite lesbar?

<!--
Pädagogisches Ziel: Studis machen erstmal ihren eigenen A11y-Check.

Lighthouse ist ein Open-Source-Tool von Google, in Chrome integriert.
- Audit-Tab im DevTools
- Wählt „Accessibility"
- Klick „Generate report"
- Liefert Score 0-100 und konkrete Fixes

Typische Befunde:
- Bilder ohne alt
- Inputs ohne label
- Schlechter Kontrast
- Fehlender lang-Attribut

Lighthouse ist nicht perfekt — findet ~30% der A11y-Probleme. Aber als Start sehr gut.

Manuelle Tests sind wichtig: nur Tastatur, mit Screen-Reader (VoiceOver/NVDA), mit Zoom 200%, mit ausgeschalteten Bildern.
-->

---

# Zusammenfassung

**Netzwerk:** IP-Adresse (Endgerät) + MAC (lokales Netz) + Port (Programm). 4 TCP/IP-Schichten mit Encapsulation. DNS löst Namen in IPs auf. HTTP transportiert Daten.

**Browser-Synthese:** URL → DNS → TCP → TLS → HTTP → HTML/CSS/JS → Pixel.

**CSS:** Selektoren + Spezifizität + Box-Model + Flexbox/Grid + Responsive.

**A11y:** **BFSG/EAA ab 28.06.2025 Pflicht.** WCAG POUR (Perceivable · Operable · Understandable · Robust). Semantisches HTML als Foundation, ARIA als Ergänzung.

→ **In Kap 3** schauen wir an: was tun, wenn HTML+CSS da sind und nichts mehr passiert? **JavaScript** macht es interaktiv.

<!--
Recap.

Großer Bogen dieses Kapitels:
- Wie reisen Daten (Netzwerk-Schichten, Adressen, Protokolle)
- Wie wird HTML hübsch (CSS-Anatomie + Selektoren + Layout)
- Wie wird es barrierefrei (BFSG + WCAG + semantisches HTML + ARIA)

Synthese Block F ist die zentrale klausur-fähige Aufgabe: URL bis Pixel in 7 Schritten.

A11y ist die wichtigste neue rechtliche Pflicht seit BFSG/EAA 2025. Studis müssen das wissen — werden's in der Praxis brauchen.

Anschluss zu Kap 3:
- Was kann JS, was nicht
- DOM-Manipulation
- Events
- Frameworks-Vorschau (React, Vue, Angular)
- Hands-On: Dark-Mode, To-Do
-->