1143 lines
32 KiB
Markdown
1143 lines
32 KiB
Markdown
---
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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.
|
||
-->
|
||
|
||
---
|
||
|
||
# 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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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
|
||
-->
|