651 lines
17 KiB
Markdown
651 lines
17 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 1: Geschichte, Grundlagen & HTML"
|
||
---
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #d63384;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h1 {
|
||
color: #a02060; /* darker raspberry */
|
||
}
|
||
section.invert h1 {
|
||
color: #fff;
|
||
}
|
||
h2 {
|
||
color: #1f2937; /* dark gray, almost black */
|
||
}
|
||
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: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: black -->
|
||
|
||
|
||
|
||
# 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: "" -->
|
||
|
||
|
||
# Die 5 Komponenten
|
||
|
||
| Komponente | Funktion |
|
||
|------------|----------|
|
||
| **Rechenwerk (ALU)** | Führt Berechnungen durch |
|
||
| **Steuerwerk** | Interpretiert Befehle, steuert Ablauf |
|
||
| **Speicherwerk** | Speichert Programme UND Daten |
|
||
| **Ein-/Ausgabe** | Tastatur, Bildschirm, Netzwerk |
|
||
| **Bus-System** | Verbindet alle Komponenten |
|
||
|
||
**Wichtig:** Programme und Daten **gemeinsam** im Speicher!
|
||
|
||
<!--
|
||
VON-NEUMANN-ARCHITEKTUR (1945): Grundlage aller modernen Computer
|
||
5 KOMPONENTEN:
|
||
- ALU (Arithmetic Logic Unit): Rechnet (+, -, ×, ÷) und vergleicht (>, <, =)
|
||
- Steuerwerk: Holt Befehle, dekodiert sie, steuert Ausführung (Fetch-Decode-Execute)
|
||
- Speicherwerk: RAM (flüchtig) + ROM (permanent), enthält Code UND Daten
|
||
- Ein-/Ausgabe (I/O): Tastatur, Maus, Bildschirm, Netzwerk, USB, Sensoren
|
||
- Bus-System: Adressbus (wo), Datenbus (was), Steuerbus (wie)
|
||
KERNPRINZIP: Stored Program Concept - Programme im selben Speicher wie Daten
|
||
VORHER (z.B. ENIAC): Programme durch Umstecken von Kabeln, tagelange Arbeit
|
||
NACHHER: Programme als austauschbare Daten → Flexibilität, Software-Industrie möglich
|
||
PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program Concept
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Von-Neumann-Architektur: Bedeutung
|
||
|
||
**Ohne Von-Neumann-Architektur:**
|
||
- Kein Betriebssystem
|
||
- Keine Apps
|
||
- Kein Multitasking
|
||
- Keine Updates bzw. Veränderungen am Computer System
|
||
|
||
**Die meisten Computer** basieren auf diesem Prinzip:
|
||
Laptop, Smartphone, Server, Spielkonsole...
|
||
|
||
**Ausnahme:** Mikrocontroller & DSPs nutzen oft die **Harvard-Architektur**
|
||
(separate Speicher für Code und Daten → schneller für Echtzeitanwendungen)
|
||
|
||
<!--
|
||
BEDEUTUNG VON-NEUMANN-ARCHITEKTUR:
|
||
- Betriebssystem möglich: Lädt verschiedene Programme aus gleichem Speicher
|
||
- Apps installierbar: Können gelöscht/installiert werden ohne Hardware-Änderung
|
||
- Multitasking: Mehrere Programme gleichzeitig im Speicher
|
||
- Updates: Software austauschbar, Hardware bleibt gleich
|
||
- Universalrechner: Gleiche Hardware für Text, Spiele, Video, Wissenschaft
|
||
HARVARD-ARCHITEKTUR (Alternative):
|
||
- Separate Speicher für Code und Daten
|
||
- Vorteil: Schneller (paralleler Zugriff), sicherer (Code nicht überschreibbar)
|
||
- Nachteil: Weniger flexibel, aufwändiger
|
||
- Anwendung: Mikrocontroller (Arduino, ESP32), DSPs, einige ARM-Chips
|
||
MODERNE CPUs: Modified Harvard (L1-Cache getrennt für Speed, RAM gemeinsam für Flexibilität)
|
||
PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beispiele
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# HTML Metadaten
|
||
|
||
```html
|
||
<html>
|
||
<head>
|
||
<title>Im Browsertab als Überschrift sichtbar</title>
|
||
|
||
<meta name="description" content="" />
|
||
|
||
<meta name="og:image" content="https://...." />
|
||
</head>
|
||
|
||
...
|
||
|
||
</html>
|
||
```
|
||
|
||
- <small>*Webseiten werden nicht nur von Menschen besucht, sondern auch von Suchmaschinen, Programmen, Bots etc.*</small>
|
||
- <small>*Metadaten helfen bspw. auch Screen-Readern beim "Verstehen" der Inhalte*</small>
|
||
|
||
<!--
|
||
HEAD-BEREICH: Metadaten, nicht sichtbar im Browser-Fenster
|
||
WICHTIGE META-TAGS:
|
||
- <title>: Browser-Tab, Lesezeichen, Suchergebnis-Titel
|
||
- <meta name="description">: Suchergebnis-Snippet (max. 160 Zeichen)
|
||
- <meta name="viewport">: Mobile Darstellung (width=device-width)
|
||
- <meta charset="UTF-8">: Zeichenkodierung (Umlaute!)
|
||
OPEN GRAPH (og:*): Social Media Vorschau (Facebook, LinkedIn, WhatsApp)
|
||
- og:title, og:description, og:image, og:url
|
||
TWITTER CARDS: twitter:card, twitter:title, twitter:image
|
||
SEO-RELEVANZ: Google nutzt title + description für Ranking und Snippet
|
||
ACCESSIBILITY: <html lang="de"> für Screenreader-Aussprache
|
||
PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta-Tags
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Wie nutzen Menschen das Web?
|
||
|
||
| Eingabe | Nutzungsweise |
|
||
|---------|---------------|
|
||
| **Maus** | Klicken, Scrollen |
|
||
| **Tastatur** | Tab-Navigation, Enter, Pfeiltasten |
|
||
| **Screenreader** | Vorlesen von Inhalten (NVDA, VoiceOver, JAWS) |
|
||
| **Sprachsteuerung** | "Klicke auf Anmelden" |
|
||
| **Augensteuerung** | Eye-Tracking |
|
||
| **Switch-Geräte** | Ein-/Aus-Schalter |
|
||
|
||
→ **Nicht alle nutzen Maus + Bildschirm!**
|
||
|
||
<!--
|
||
ACCESSIBILITY (a11y): a + 11 Buchstaben + y
|
||
STATISTIK: ~15% der Weltbevölkerung haben eine Behinderung (WHO)
|
||
ARTEN VON EINSCHRÄNKUNGEN:
|
||
- Permanent: Blindheit, Taubheit, motorische Einschränkungen
|
||
- Temporär: Gebrochener Arm, Augen-OP, Ohrenentzündung
|
||
- Situativ: Helle Sonne (Kontrast), laute Umgebung (kein Audio), Baby auf Arm (eine Hand)
|
||
ASSISTIVE TECHNOLOGIEN:
|
||
- Screenreader: NVDA (Windows, kostenlos), VoiceOver (Apple), JAWS (kommerziell)
|
||
- Braillezeilen: Taktile Ausgabe für Blinde
|
||
- Switch-Geräte: Für motorische Einschränkungen
|
||
- Spracheingabe: Dragon NaturallySpeaking, Siri, Google Assistant
|
||
WCAG: Web Content Accessibility Guidelines (A, AA, AAA)
|
||
EUROPEAN ACCESSIBILITY ACT: Seit Juni 2025 verpflichtend!
|
||
PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Warum "Barrierefreiheit"?
|
||
|
||
**Rechtlich:**
|
||
- EU: European Accessibility Act (seit Juni 2025 in Kraft!)
|
||
- DE: BITV 2.0 (Behörden), Privatwirtschaft betroffen
|
||
|
||
**Ethisch:**
|
||
- Teilhabe für alle Menschen
|
||
- Digitale Inklusion
|
||
|
||
**Praktisch:**
|
||
- Bessere UX für **alle** (SEO, Mobile, ältere Menschen)
|
||
- Größerer Markt (~15% der Bevölkerung)
|
||
|
||
<!--
|
||
RECHTLICHER RAHMEN:
|
||
- European Accessibility Act (EAA): EU-Richtlinie, seit 28. Juni 2025 in Kraft
|
||
- Betrifft: E-Commerce, Banking, Telekommunikation, Transport, E-Books
|
||
- BITV 2.0: Barrierefreie Informationstechnik-Verordnung (DE, öffentliche Stellen)
|
||
- BFSG: Barrierefreiheitsstärkungsgesetz (DE-Umsetzung des EAA)
|
||
- Strafen: Bis zu 100.000€ Bußgeld möglich
|
||
CURB-CUT-EFFEKT:
|
||
- Bordsteinabsenkung für Rollstuhlfahrer → hilft auch Kinderwagen, Rollkoffern, Fahrrädern
|
||
- Untertitel für Gehörlose → helfen in lauter Umgebung, beim Sprachlernen
|
||
- Kontrastreiche Farben → besser bei Sonnenlicht, für ältere Menschen
|
||
BUSINESS CASE:
|
||
- 15% Zielgruppe (Menschen mit Behinderung)
|
||
- +20% ältere Menschen (Sehschwäche, motorische Einschränkungen)
|
||
- SEO-Vorteile: Alt-Texte, semantisches HTML = besser für Google
|
||
PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Barrieren im Netz vermeiden (a11y)
|
||
|
||
**Tastatur-Test:**
|
||
- Alle Funktionen nur mit Tab + Enter nutzbar?
|
||
- Fokus immer sichtbar?
|
||
- Logische Tab-Reihenfolge?
|
||
|
||
**Screenreader-Test:**
|
||
- VoiceOver (Mac): `Cmd + F5`
|
||
- NVDA (Windows): Gratis-Download
|
||
|
||
**Tools:**
|
||
- axe DevTools, WAVE (Browser-Extensions)
|
||
- Lighthouse (in Chrome DevTools)
|
||
|
||
<!--
|
||
Automatische Tests finden ~30% der Probleme
|
||
Manuelles Testen unverzichtbar
|
||
Echte NutzerInnen einbeziehen = Gold-Standard
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Das TCP/IP-Modell
|
||
|
||
| Schicht | Name | Aufgabe | Protokolle |
|
||
|---------|------|---------|------------|
|
||
| **4** | Anwendung | Was? Welcher Dienst? | HTTP, DNS, SMTP |
|
||
| **3** | Transport | Zuverlässigkeit, Ports | TCP, UDP |
|
||
| **2** | Internet | Routing, globale Adressen | IP |
|
||
| **1** | Netzzugang | Lokale Übertragung | Ethernet, WLAN |
|
||
|
||
**4 Schichten. Das reicht, um das Internet zu verstehen.**
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
- TCP/IP = das echte Internet
|
||
- 4 Schichten:
|
||
- Anwendung: Was will ich? (HTTP, DNS, Mail)
|
||
- Transport: Kommt an? Welches Programm? (TCP, UDP)
|
||
- Internet: Wie zum Zielrechner? (IP)
|
||
- Netzzugang: Wie zum nächsten Gerät? (Ethernet, WLAN)
|
||
- KLAUSUR: Welches Protokoll → welche Schicht
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Dateneinheiten pro Schicht
|
||
|
||
| Schicht | Name | Dateneinheit | Was kommt hinzu? |
|
||
|---------|------|--------------|------------------|
|
||
| Anwendung | HTTP, DNS | **Daten** | – |
|
||
| Transport | TCP, UDP | **Segment** | Ports, Sequenznummern |
|
||
| Internet | IP | **Paket** | IP-Adressen |
|
||
| Netzzugang | Ethernet | **Frame** | MAC-Adressen, Prüfsumme |
|
||
|
||
Merkhilfe: **D**aten → **S**egment → **P**aket → **F**rame
|
||
(„**D**er **S**ache **P**raktischer **F**olgen")
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
- Glossar-Begriffe jetzt eingeordnet:
|
||
- Anwendung: Daten/Message
|
||
- Transport: Segment
|
||
- Internet: Paket
|
||
- Netzzugang: Frame
|
||
- Merkhilfe: D-S-P-F (eigene erfinden!)
|
||
- KLAUSUR: Begriff → Schicht
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# IP vs. MAC vs. Port
|
||
|
||
| | IP-Adresse | MAC-Adresse | Port |
|
||
|---|-----------|-------------|------|
|
||
| **Frage** | Welcher Rechner? | Welches Gerät nebenan? | Welches Programm? |
|
||
| **Reichweite** | Global | Lokal (1 Hop) | Auf einem Rechner |
|
||
| **Ändert sich?** | Nein | Ja, bei jedem Hop | Nein |
|
||
| **Schicht** | Internet (IP) | Netzzugang (Ethernet) | Transport (TCP/UDP) |
|
||
| **Beispiel** | 212.132.79.37 | aa:bb:cc:dd:ee | 443 |
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
- KLAUSUR: Diese Tabelle
|
||
- IP: Welcher Rechner? Global. Bleibt gleich.
|
||
- MAC: Welcher Nachbar? Lokal. Ändert sich.
|
||
- Port: Welches Programm? Bleibt gleich.
|
||
- Merken: NUR MAC ändert sich unterwegs
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Der 3-Way-Handshake
|
||
|
||
```
|
||
Client (dein Laptop) Server
|
||
| |
|
||
|-------- SYN (Seq=1000) --------------->|
|
||
| "Ich will reden" |
|
||
| |
|
||
|<--- SYN-ACK (Seq=5000, Ack=1001) ------|
|
||
| "OK, ich auch. Ich starte bei 5000"|
|
||
| |
|
||
|-------- ACK (Ack=5001) --------------->|
|
||
| "Verstanden, los geht's" |
|
||
| |
|
||
| [ Verbindung steht ] |
|
||
```
|
||
|
||
**SYN** = Synchronize · **ACK** = Acknowledge
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
- 3 Pakete → Verbindung steht
|
||
- 1. Client SYN: "Will Verbindung, starte bei 1000"
|
||
- 2. Server SYN-ACK: "OK, ich starte bei 5000, erwarte 1001"
|
||
- 3. Client ACK: "Verstanden, erwarte 5001"
|
||
- Seq-Nr wichtig: Beide wissen nächstes erwartetes Byte
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# TCP vs. UDP
|
||
|
||
| | TCP | UDP |
|
||
|---|-----|-----|
|
||
| **Verbindung** | Ja (Handshake) | Nein |
|
||
| **Reihenfolge** | Garantiert | Nicht garantiert |
|
||
| **Verlorene Pakete** | Werden nachgefordert | Gehen verloren |
|
||
| **Overhead** | Höher | Niedriger |
|
||
| **Use Cases** | Web, Email, Downloads | Video-Calls, Gaming, DNS |
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
- Zwei Transport-Protokolle
|
||
- TCP: zuverlässig
|
||
- Handshake, Seq-Nr, Bestätigungen, Neuübertragung
|
||
- Perfekt für Web, Downloads (nichts darf fehlen)
|
||
- UDP: schneller
|
||
- Kein Handshake, keine Bestätigungen
|
||
- Verloren = weg
|
||
- Perfekt für Video-Calls (Verzögerung schlimmer als Verlust)
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# HTTP-Methoden
|
||
|
||
| Methode | Bedeutung | Beispiel |
|
||
|---------|-----------|----------|
|
||
| **GET** | Daten abrufen | Seite laden |
|
||
| **POST** | Daten senden | Formular absenden |
|
||
| **PUT** | Daten ersetzen | Profil aktualisieren |
|
||
| **DELETE** | Daten löschen | Account löschen |
|
||
|
||
```http
|
||
GET /index.html HTTP/1.1
|
||
POST /login HTTP/1.1
|
||
```
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
|
||
Zum Schluss noch HTTP-Methoden.
|
||
|
||
GET ist das häufigste – "gib mir was". Wenn ihr eine URL aufruft, ist das ein GET.
|
||
|
||
POST schickt Daten zum Server – wenn ihr ein Formular abschickt.
|
||
|
||
PUT und DELETE sind für APIs – ersetzen oder löschen von Ressourcen.
|
||
|
||
Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# HTTP Status-Codes
|
||
|
||
```http
|
||
HTTP/1.1 200 OK
|
||
HTTP/1.1 404 Not Found
|
||
HTTP/1.1 500 Internal Server Error
|
||
```
|
||
|
||
| Code-Bereich | Bedeutung |
|
||
|--------------|-----------|
|
||
| **2xx** | Erfolg (200 OK, 201 Created) |
|
||
| **3xx** | Umleitung (301 Moved, 304 Not Modified) |
|
||
| **4xx** | Client-Fehler (400 Bad Request, 404 Not Found) |
|
||
| **5xx** | Server-Fehler (500 Internal Error, 503 Unavailable) |
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
|
||
Status-Codes sagen euch, was passiert ist.
|
||
|
||
2xx heißt: Alles gut. 200 OK ist der Normalfall.
|
||
|
||
3xx heißt: Umleitung. Die Seite ist woanders.
|
||
|
||
4xx heißt: Ihr habt was falsch gemacht. 404 kennt ihr – Seite nicht gefunden. 403 heißt: Zugriff verweigert.
|
||
|
||
5xx heißt: Der Server hat ein Problem. 500 ist ein generischer Fehler, 503 heißt: Server überlastet.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Zusammenfassung Teil 1
|
||
|
||
**Der Ablauf:**
|
||
1. DNS (UDP:53) → Name zu IP
|
||
2. TCP-Handshake (SYN → SYN-ACK → ACK)
|
||
3. HTTP-Request (GET /...)
|
||
4. HTTP-Response (200 OK + HTML)
|
||
|
||
**Die Konzepte:**
|
||
- 4 Schichten: Anwendung → Transport → Internet → Netzzugang
|
||
- IP bleibt gleich, MAC ändert sich pro Hop
|
||
- Ports identifizieren Programme
|
||
- Encapsulation: Jede Schicht verpackt die darüberliegende
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
|
||
Das ist die Zusammenfassung für Teil 1. Das solltet ihr können:
|
||
|
||
Den Ablauf: DNS, TCP-Handshake, HTTP-Request, HTTP-Response.
|
||
|
||
Die Schichten und ihre Protokolle.
|
||
|
||
Den Unterschied zwischen IP und MAC – was bleibt gleich, was ändert sich.
|
||
|
||
Was Ports tun.
|
||
|
||
Wie Encapsulation funktioniert.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Spezifität: Welche Regel gewinnt?
|
||
|
||
| Selektor | Spezifität |
|
||
|----------|------------|
|
||
| Element (`p`) | 0,0,0,1 |
|
||
| Klasse (`.wichtig`) | 0,0,1,0 |
|
||
| ID (`#header`) | 0,1,0,0 |
|
||
| Inline (`style="..."`) | 1,0,0,0 |
|
||
|
||
```css
|
||
p { color: blue; } /* 0,0,0,1 */
|
||
.text { color: green; } /* 0,0,1,0 → gewinnt */
|
||
#intro { color: red; } /* 0,1,0,0 → gewinnt über beide */
|
||
```
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
|
||
Wenn mehrere Regeln auf ein Element zutreffen, gewinnt die spezifischere.
|
||
|
||
Spezifität wird in vier Zahlen gemessen. Von links nach rechts: Inline, IDs, Klassen, Elemente.
|
||
|
||
Ein Element-Selektor hat 0,0,0,1. Eine Klasse hat 0,0,1,0. Eine ID hat 0,1,0,0.
|
||
|
||
0,0,1,0 schlägt 0,0,0,99 – auch hundert Element-Selektoren schlagen keine Klasse.
|
||
|
||
Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Responsive Design
|
||
|
||
```css
|
||
/* Mobile First: Basis-Styles */
|
||
.container {
|
||
padding: 1rem;
|
||
background: white;
|
||
}
|
||
|
||
/* Ab 768px (Tablet): Anpassungen */
|
||
@media (min-width: 768px) {
|
||
.container {
|
||
padding: 2rem;
|
||
background: red;
|
||
}
|
||
}
|
||
|
||
/* Ab 1024px (Desktop): Weitere Anpassungen */
|
||
@media (min-width: 1024px) {
|
||
.container {
|
||
background: green;
|
||
}
|
||
}
|
||
```
|
||
|
||
<!--
|
||
SPEAKER NOTES:
|
||
|
||
Responsive Design: Die Seite passt sich der Bildschirmgröße an.
|
||
|
||
Mobile First: Ihr schreibt zuerst die Styles für kleine Screens. Dann fügt ihr mit @media-Queries Anpassungen für größere Screens hinzu.
|
||
|
||
min-width heißt: "ab dieser Breite". Also: Basis gilt für alle. Ab 768px gelten zusätzliche Regeln. Ab 1024px noch mehr.
|
||
|
||
Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute Standard.
|
||
-->
|