libretech
1731aa8c40
bogen-treu nach docs/223015c/03-interaktivitaet-javascript-bogen.md: - 2 leads: kapitel-intro, 'statisch ist langweilig' - was-kann-JS-tabelle (mit sicherheits-grenzen erklärung), JS-timeline (1995 brendan eich → 2009 node → 2015 ES6 → heute TS) - JS einbinden (external/inline/module), js-console demo reuse - variablen (let/const/var, const default), datentypen (6 grundtypen + arrays/objects) - js-arrays + js-objects demo reuse, funktionen (declaration + arrow) - js-loops demo reuse, kontrollstrukturen (if/else, ternär, switch) - DOM lead, dom-tree demo reuse, querySelector (CSS-selektoren wiederverwendbar) - js-manipulate demo reuse (textContent/innerHTML/setAttribute/classList) - js-create demo reuse (createElement/appendChild/remove) - events lead, js-event-listener demo reuse, häufige-events-tabelle (click/input/submit/keydown/load/DOMContentLoaded) - js-preventdefault demo reuse, js-darkmode demo reuse, js-todo demo reuse, js-fetch demo reuse, js-localstorage demo reuse - frameworks lead, React/Vue/Angular/Svelte/Astro übersichtstabelle (KEINE logo-galerie), library-vs-framework (inversion of control) - selbstlernen mini-projekt (dark-mode / to-do / API), zusammenfassung des ganzen kurses reuse-demos: js-console, js-arrays, js-objects, js-loops, dom-tree, js-manipulate, js-create, js-event-listener, js-preventdefault, js-darkmode, js-todo, js-fetch, js-localstorage (13 demos reused) no NEU demos in dieser session per klausur-themen-vorschlag: JS NICHT klausurrelevant. lernziele auf verstehen-niveau (kein code-schreiben in klausur). streichungen vs altem 03-interaktivitaet-javascript.md (1050 zeilen, 49 slides): - framework-logo-galerie-folien (react/vue/svelte/astro/webpack/vite/parcel als jeweils eigene folie) → eine übersichts-folie - doppelte 'was kann JS'-folien → eine - lange hands-on-codes als folie → in speaker-notes oder selbstlernen verlinken klausurfolien.md regeneriert: 20 slides (8 aus kap1, 11 aus kap2, 0 aus kap3 → bestätigt JS-nicht-klausurrelevant-design) build geht durch
724 lines
20 KiB
Markdown
724 lines
20 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||
title: Grundlagen IT- und Internettechnik
|
||
---
|
||
<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: #1a1a2e;
|
||
color: #d63384;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
}
|
||
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;
|
||
}
|
||
</style>
|
||
|
||
<!--
|
||
╔═══════════════════════════════════════════════════════════════════╗
|
||
║ AUTO-GENERATED FILE - DO NOT EDIT MANUALLY ║
|
||
║ ║
|
||
║ This file is generated by: make klausur ║
|
||
║ Source: scripts/extract-klausur.sh ║
|
||
║ ║
|
||
║ To update, edit the source slides and re-run make klausur ║
|
||
╚═══════════════════════════════════════════════════════════════════╝
|
||
-->
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Grundlagen IT- und Internettechnik
|
||
|
||
**223015c** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Sommersemester 2026**
|
||
|
||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Von-Neumann-Architektur · 5 Komponenten
|
||
|
||
| # | Komponente | Aufgabe |
|
||
|---|------------|---------|
|
||
| 1 | **Steuerwerk** (Control Unit) | holt Befehl, entscheidet was zu tun ist |
|
||
| 2 | **Rechenwerk** (ALU) | führt Rechnung / Vergleich aus |
|
||
| 3 | **Speicher** (Memory) | hält Daten *und* Programm |
|
||
| 4 | **Eingabe / Ausgabe** (I/O) | Tastatur, Bildschirm, Netzwerk |
|
||
| 5 | **Bus** (Verbindung) | transportiert Daten zwischen allen |
|
||
|
||
**Schlüssel:** Speicher hält *beides* — Daten + Programm. (Stored Program.)
|
||
|
||
<!--
|
||
Klausurfähig: die 5 Komponenten und ihre Aufgaben benennen.
|
||
|
||
Wo seht ihr das in eurem eigenen Gerät?
|
||
- Steuerwerk + Rechenwerk = CPU
|
||
- Speicher = RAM (flüchtig) + SSD (persistent)
|
||
- I/O = USB-Ports, Display, Audio
|
||
- Bus = im Chip (Intern), zwischen Chips (PCIe, USB)
|
||
|
||
Die Architektur ist seit 1945 stabil. Quantencomputer brechen sie auf (kein klassisches stored program). Aber jeder PC, Mac, Smartphone, jeder Server, jede Spielkonsole folgt ihr noch immer.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Internet-Timeline · 4 Milestones
|
||
|
||
| Jahr | Was | Was hat es verändert |
|
||
|------|-----|----------------------|
|
||
| **1969** | ARPANET | Erstes paket-vermitteltes Netzwerk, 4 Knoten |
|
||
| **1971** | Email (Ray Tomlinson) | Erste Nutzung des `@`-Zeichens |
|
||
| **1983** | TCP/IP | Wurde Standard-Protokoll des ARPANET |
|
||
| **1989** | **WWW** (Berners-Lee, CERN) | HTML, HTTP, URL — das Web wie wir es kennen |
|
||
|
||
1993: Mosaic-Browser → Internet wird *populär*.
|
||
|
||
<!--
|
||
Klausurfähig: die 4 Meilensteine und ihre Bedeutung.
|
||
|
||
Anmerkungen:
|
||
- 1969 ARPANET: noch militärisch + Forschung. Wenige Knoten.
|
||
- 1971 Email: Ray Tomlinson schickt die erste E-Mail mit @-Zeichen, das er gewählt hat um „User AT Maschine" zu trennen. Heute auf jedem Tastatur als Standard.
|
||
- 1983 TCP/IP: Vint Cerf + Bob Kahn. ARPANET wechselt am 1. Jan 1983 von NCP zu TCP/IP. Das ist die „Geburt des modernen Internets" im technischen Sinne.
|
||
- 1989 WWW: Tim Berners-Lee am CERN. Er erfindet HTTP (Protokoll), HTML (Markup) und URL (Adress-System) — drei Standards, eine Person.
|
||
- 1993 Mosaic: erste GUI-Browser, der Bilder im Text-Fluss anzeigen konnte. Damit explodierte die Web-Nutzung.
|
||
|
||
Internet ist nicht Web — Internet ist das Netzwerk, Web ist eine Anwendung darauf. Aber im Volksmund verwechselt.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# HTML-Anatomie
|
||
|
||
```html
|
||
<a href="https://librete.ch">Mein Link</a>
|
||
```
|
||
|
||
| Bestandteil | Was |
|
||
|-------------|-----|
|
||
| `<a` | **Opening-Tag** mit Tag-Namen |
|
||
| `href="https://..."` | **Attribut** (Name + Wert) |
|
||
| `>` | Ende des Opening-Tags |
|
||
| `Mein Link` | **Inhalt** des Elements |
|
||
| `</a>` | **Closing-Tag** |
|
||
|
||
Alles zusammen = ein **Element.**
|
||
|
||
<!--
|
||
Klausurfähig. Studis sollen die Bestandteile eines HTML-Elements unterscheiden können:
|
||
- Opening-Tag
|
||
- Closing-Tag
|
||
- Attribute (Name=Wert)
|
||
- Inhalt
|
||
- Element = alles zusammen
|
||
|
||
Achtung: einige Tags sind „self-closing" und haben keinen Closing-Tag:
|
||
- `<img src="..." alt="...">`
|
||
- `<br>`
|
||
- `<input>`
|
||
- `<meta>`
|
||
|
||
Diese werden auf der nächsten Folie behandelt.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Document-Struktur: das Grundgerüst
|
||
|
||
```html
|
||
<!DOCTYPE html>
|
||
<html lang="de">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
<title>Meine Seite</title>
|
||
<link rel="stylesheet" href="style.css">
|
||
</head>
|
||
<body>
|
||
<h1>Hallo Welt</h1>
|
||
<!-- alle sichtbaren Inhalte -->
|
||
</body>
|
||
</html>
|
||
```
|
||
|
||
<!--
|
||
Klausurfähig: die DOCTYPE + head + body-Struktur reproduzieren können.
|
||
|
||
Was passiert wo?
|
||
- DOCTYPE: sagt dem Browser „das ist HTML5". Ohne DOCTYPE: Quirks-Mode (alte Browser-Verhaltensweisen).
|
||
- html-Element + lang: Wurzel-Element + Sprache
|
||
- head: alles, was *nicht* sichtbar ist (Meta, Title, CSS-Links, Scripts)
|
||
- meta charset: sagt Browser, wie die Byte zu interpretieren sind (UTF-8 = international, alle Sprachen)
|
||
- meta viewport: für Mobile-Rendering, ohne zoomt iPhone alles auf 980px
|
||
- title: Browser-Tab-Titel + Lesezeichen-Name
|
||
- link stylesheet: CSS einbinden
|
||
- body: alle sichtbaren Inhalte
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Semantische HTML-Tags
|
||
|
||
| Tag | Bedeutung | Beispiel |
|
||
|-----|-----------|----------|
|
||
| `<header>` | Kopfbereich (Logo, Nav) | oben auf der Seite |
|
||
| `<nav>` | Navigations-Menü | Hauptmenü |
|
||
| `<main>` | Hauptinhalt | das eigentliche Thema |
|
||
| `<section>` | Thematischer Abschnitt | Kapitel der Seite |
|
||
| `<article>` | eigenständiger Inhalt | Blog-Post, News-Beitrag |
|
||
| `<aside>` | Seiten-Inhalt | Sidebar, Werbung |
|
||
| `<footer>` | Fußbereich | Impressum, Copyright |
|
||
|
||
**Vorteil:** Screen-Reader, Suchmaschinen + andere Entwickler verstehen die Struktur.
|
||
|
||
<!--
|
||
Klausurfähig: die 7 semantischen Tags und ihre Bedeutung.
|
||
|
||
Vor HTML5 (2008) gab es nur `<div>`. Man hat alles in div verpackt und mit Klassen markiert: `<div class="header">`. Funktioniert visuell — aber Maschinen (Screen-Reader, Suchmaschinen) verstehen nichts.
|
||
|
||
Mit semantischen Tags:
|
||
- Screen-Reader kann „Hauptnavigation überspringen" anbieten
|
||
- Google versteht, was Haupt-Inhalt der Seite ist (SEO-Boost)
|
||
- Andere Entwickler lesen den Code schneller
|
||
|
||
Faustregel: wenn ein Tag den *Zweck* eines Bereichs ausdrückt — semantisch. Wenn nur Styling — div.
|
||
|
||
Drei A11y-relevante Anti-Patterns:
|
||
- `<div onclick="...">` statt `<button>` (Tastatur nicht erreichbar)
|
||
- `<a href="javascript:void(0)">` statt `<button>` (semantisch falsch)
|
||
- alles in `<div>` (keine Hierarchie für Screen-Reader)
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# 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: "" -->
|
||
|
||
|
||
# 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 — 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
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# 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
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# 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)
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# 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
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# 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: "" -->
|
||
|
||
|
||
# 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: "" -->
|
||
|
||
|
||
# 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
|
||
|
||
```
|
||
+------------------------+
|
||
| 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.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# 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: "" -->
|
||
|
||
|
||
# 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.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# 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
|
||
-->
|