50 KiB
marp, theme, paginate, backgroundColor, header, footer, title
| marp | theme | paginate | backgroundColor | header | footer | title |
|---|---|---|---|---|---|---|
| true | gaia | true | Grundlagen IT- und Internettechnik (223015c) | Michael Czechowski – HdM Stuttgart – WS 2025/26 | Termin 2: Netzwerke, Protokolle & CSS |
Grundlagen IT- und Internettechnik
223015c · Modul "Technik 1" · 1. Semester Digital- und Medienwirtschaft Hochschule der Medien Stuttgart
Wintersemester 2025/26
https://librete.ch/hdm/223015c/
Internet- Grundlagen
Netzwerke, Protokolle & CSS
Agenda
Teil 1: Netzwerke & Protokolle
- Glossar: Die wichtigsten Begriffe
- Das Schichtenmodell: Wie das Internet organisiert ist
- Die Reise eines Klicks: Was passiert bei einem Seitenaufruf?
Teil 2: CSS
- Grundlagen, Selektoren, Spezifität
- Box-Modell, Farben, Einheiten
Ressourcen zum Selbstlernen
- CODE CRISPIES: https://codecrispi.es/
- Online Code-Editor: https://codepen.io/pen/
- MDN (Mozilla Developer Network): https://developer.mozilla.org/de/
- Flexbox-Spiel: https://flexboxfroggy.com/
- Grid-Spiel: https://cssgridgarden.com/
Teil 1: Netzwerke & Protokolle
Die Infrastruktur des Webs
Glossar: Die Landkarte
| Begriff | Was ist das? | Analogie |
|---|---|---|
| Client | Der, der fragt (Browser) | Gast im Restaurant |
| Server | Der, der antwortet | Küche im Restaurant |
| Request | Die Anfrage | Bestellung |
| Response | Die Antwort | Das Essen |
| Protokoll | Regeln für Kommunikation | Speisekarte + Bestellablauf |
| Host | Ein Rechner im Netz | Ein Haus mit Adresse |
Glossar: Adressen & Identitäten
| Begriff | Was ist das? | Beispiel |
|---|---|---|
| IP-Adresse | Globale Adresse im Internet | 212.132.79.37 |
| MAC-Adresse | Hardware-Adresse der Netzwerkkarte | aa:bb:cc:dd:ee:ff |
| Port | "Türnummer" auf einem Rechner | 80, 443, 22 |
| DNS | Telefonbuch: Name → IP | hdm-stuttgart.de → IP |
| Domain | Menschenlesbarer Name | hdm-stuttgart.de |
Glossar: Daten unterwegs
| Begriff | Was ist das? | Schicht |
|---|---|---|
| Paket | Daten + IP-Header | Internet (Layer 3) |
| Segment | Daten + TCP-Header | Transport (Layer 4) |
| Frame | Daten + MAC-Header | Netzzugang (Layer 2) |
| Header | Metadaten am Anfang | Jede Schicht |
| Payload | Die eigentlichen Nutzdaten | Der Inhalt |
Glossar: Netzwerk-Eigenschaften
| Begriff | Was ist das? | Einheit |
|---|---|---|
| Latenz | Verzögerung (hin + zurück) | Millisekunden |
| Bandbreite | Datenmenge pro Zeiteinheit | Mbit/s |
| Hop | Ein Sprung zum nächsten Router | – |
| Round-Trip | Hin- und Rückweg | – |
| Ping | "Bist du da?" + Antwort | ms |
Glossar: Protokolle
| Protokoll | Wofür? | Port | Schicht |
|---|---|---|---|
| HTTP | Webseiten übertragen | 80 | Anwendung |
| HTTPS | HTTP + Verschlüsselung | 443 | Anwendung |
| TCP | Zuverlässige Übertragung | – | Transport |
| UDP | Schnelle Übertragung | – | Transport |
| IP | Routing durchs Internet | – | Internet |
| DNS | Namen → IP-Adressen | 53 | Anwendung |
Das Schichtenmodell
Warum ist Netzwerk-Kommunikation in Schichten organisiert?
Das Problem: Komplexität
Zwischen dir und einer Webseite liegen:
Dein Browser
↓
Deine Netzwerkkarte (WLAN oder Ethernet)
↓
Router im Flur / zu Hause
↓
Netzwerk der HdM / deines Providers
↓
Das Internet (dutzende Router)
↓
Netzwerk des Ziel-Servers
↓
Der Webserver
Jede Komponente "spricht" anders.
Die Lösung: Arbeitsteilung
Statt dass jedes Programm alles können muss: Aufgaben aufteilen.
| Wer? | Aufgabe | Typische Geräte |
|---|---|---|
| Browser/App | Was will ich? | Laptop, Handy, Server |
| TCP/UDP | Kommt alles an? | – (Software) |
| IP | Welcher Rechner? | Router, Firewall |
| Ethernet/WLAN | Nächstes Gerät? | Switch, Access Point |
| Physik | Signale übertragen | Kabel, Glasfaser, Antenne |
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.
Schichten verpacken Daten
Anwendung: [ HTTP-Request: "GET /index.html" ]
↓ verpackt in
Transport: [ TCP-Header | HTTP-Request ]
↓ verpackt in
Internet: [ IP-Header | TCP-Header | HTTP-Request ]
↓ verpackt in
Netzzugang: [ Eth-Header | IP-Header | TCP | HTTP | Eth-Trailer ]
↓
Physik: 01001000 01010100 01010100...
Encapsulation: Jede Schicht packt ein. Decapsulation: Beim Empfang wird ausgepackt.
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: Daten → Segment → Paket → Frame („Der Sache Praktischer Folgen")
Warum ist das clever?
Ohne Schichten: Jede App müsste wissen, wie Ethernet-Frames gebaut werden, wie WLAN funktioniert, wie Router Pakete weiterleiten...
Mit Schichten: Der Browser sagt: "Ich will diese Seite." Alles andere übernehmen die Schichten darunter.
Austauschbarkeit: WLAN statt Ethernet? Nur Schicht 1 ändert sich. HTTP/2 statt HTTP/1? Nur Schicht 4 ändert sich.
Exkurs: OSI vs. TCP/IP
OSI (7 Schichten) TCP/IP (4 Schichten)
┌─────────────────────┐ ┌─────────────────────┐
│ 7. Anwendung │ │ │
├─────────────────────┤ │ Anwendung │
│ 6. Darstellung │ │ │
├─────────────────────┤ │ │
│ 5. Sitzung │ │ │
├─────────────────────┤ ├─────────────────────┤
│ 4. Transport │ │ Transport │
├─────────────────────┤ ├─────────────────────┤
│ 3. Vermittlung │ │ Internet │
├─────────────────────┤ ├─────────────────────┤
│ 2. Sicherung │ │ │
├─────────────────────┤ │ Netzzugang │
│ 1. Bitübertragung │ │ │
└─────────────────────┘ └─────────────────────┘
OSI = Theorie. TCP/IP = Realität.
Die drei Adressen
IP, MAC und Port – wer braucht was?
IP-Adresse: Das Endziel
212.132.79.37
- Global eindeutig (im gesamten Internet)
- Identifiziert einen Rechner
- Bleibt gleich auf dem gesamten Weg
- Analogie: Empfänger auf einem Brief
Router lesen die IP und entscheiden: "Ist das für mich? Nein → in welche Richtung weiterleiten?"
MAC-Adresse: Der nächste Schritt
aa:bb:cc:dd:ee:ff
- Lokal eindeutig (nur im lokalen Netzwerk relevant)
- Identifiziert eine Netzwerkkarte
- Ändert sich bei jedem Hop
- Analogie: "Nächstes Postamt: XY"
Funktioniert nur innerhalb eines Netzwerksegments.
Port: Das richtige Programm
212.132.79.37:443
└─── Port 443 = HTTPS
- Identifiziert ein Programm auf einem Rechner
- Ein Rechner, viele Dienste
- Analogie: Wohnungstür im Mehrfamilienhaus
| Port | Dienst |
|---|---|
| 80 | HTTP |
| 443 | HTTPS |
| 22 | SSH |
| 53 | DNS |
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 |
Die Reise eines Klicks
Was passiert, wenn du www.hdm-stuttgart.de aufrufst?
Das Szenario
Du bist im WLAN der HdM und rufst auf:
https://www.hdm-stuttgart.de
Zwischen Enter und fertiger Seite: ~200 Millisekunden.
In dieser Zeit passieren hunderte Operationen.
Die Zeitlinie
[0 ms] DNS: "Welche IP hat www.hdm-stuttgart.de?"
↓
[~20 ms] DNS-Antwort: "212.132.79.37"
↓
[~25 ms] TCP-Handshake beginnt
↓
[~50 ms] TCP-Verbindung steht
↓
[~55 ms] HTTP-Request: "GET /index.html"
↓
[~150 ms] HTTP-Response: HTML kommt zurück
↓
[~200 ms] Browser rendert die Seite
Schritt 1: DNS
"Wo wohnt hdm-stuttgart.de?"
DNS: Das Telefonbuch des Internets
Domain Name System
www.hdm-stuttgart.de → 212.132.79.37
Dein Laptop fragt sich durch:
- Browser-Cache: "War ich da kürzlich?" → Nein
- OS-Cache: "Kennt das Betriebssystem die IP?" → Nein
- Router/Provider: DNS-Server wird gefragt
Die DNS-Hierarchie
. (Root)
/|\
/ | \
.de .com .org ...
/
hdm-stuttgart
|
www
Dezentral: Niemand kennt alles. Jede Ebene kennt nur die nächste.
Der DNS-Lookup
Dein Laptop → Resolver: "Wo ist www.hdm-stuttgart.de?"
Resolver → Root (.): "Wer verwaltet .de?"
← "Frag 194.0.0.53"
Resolver → .de-Server: "Wer verwaltet hdm-stuttgart.de?"
← "Frag den Nameserver der HdM"
Resolver → HdM-NS: "Welche IP hat www?"
← "212.132.79.37"
Resolver → Dein Laptop: "Die IP ist 212.132.79.37"
DNS ist selbst Netzwerk
Die DNS-Anfrage ist ein ganz normales Paket:
| Eigenschaft | Wert |
|---|---|
| Protokoll | UDP (meistens) |
| Port | 53 |
| Inhalt | "A-Record für www.hdm-stuttgart.de?" |
DNS durchläuft alle Schichten – genau wie später HTTP.
Nach dem DNS-Lookup
Ergebnis:
www.hdm-stuttgart.de = 212.132.79.37
Diese Information wird gecached (für Minuten bis Stunden).
Nächster Schritt: Verbindung aufbauen.
Schritt 2: TCP-Handshake
"Hallo Server, bist du da?"
Warum ein Handshake?
TCP ist verbindungsorientiert:
- Beide Seiten müssen bereit sein
- Beide kennen die Sequenznummern des anderen
- Verlorene Pakete können erkannt und neu angefordert werden
Analogie: Telefonat: Klingeln → Abheben → "Hallo?" → Gespräch beginnt
Nicht: Einfach losreden und hoffen, dass jemand zuhört.
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
Nach dem Handshake
Status: Die TCP-Verbindung steht.
Client: 141.62.xxx.xxx:52431
└─── Zufälliger Port für diese Verbindung
Server: 212.132.79.37:443
└─── HTTPS-Port
Jetzt erst kann HTTP gesprochen werden.
Schritt 3: HTTP-Request
"Gib mir die Startseite"
Was dein Browser sendet
GET / HTTP/1.1
Host: www.hdm-stuttgart.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html
Accept-Language: de-DE
Connection: keep-alive
~200 Bytes Text.
GET = "Gib mir" (im Gegensatz zu POST = "Nimm das") / = "Die Startseite"
Encapsulation in Aktion
Der Request wird verpackt
Layer 4: Transport (TCP)
HTTP-Request wird zum Segment:
┌─────────────────────────────────────────────────┐
│ TCP-Header │
│ ┌─────────────┬─────────────┬─────────────────┐ │
│ │ Source Port │ Dest Port │ Sequence Number │ │
│ │ 52431 │ 443 │ 1001 │ │
│ └─────────────┴─────────────┴─────────────────┘ │
├─────────────────────────────────────────────────┤
│ Payload: "GET / HTTP/1.1..." │
└─────────────────────────────────────────────────┘
Neu: Ports + Sequenznummer
Layer 3: Network (IP)
Segment wird zum Paket:
┌─────────────────────────────────────────────────┐
│ IP-Header │
│ ┌─────────────────┬─────────────────┐ │
│ │ Source IP │ Destination IP │ │
│ │ 141.62.xxx.xxx │ 212.132.79.37 │ │
│ └─────────────────┴─────────────────┘ │
├─────────────────────────────────────────────────┤
│ TCP-Segment (unverändert) │
└─────────────────────────────────────────────────┘
Neu: IP-Adressen
Layer 2: Data Link (Ethernet)
Paket wird zum Frame:
┌─────────────────────────────────────────────────┐
│ Ethernet-Header │
│ ┌─────────────────┬─────────────────┐ │
│ │ Source MAC │ Destination MAC │ │
│ │ aa:bb:cc:dd:ee │ 11:22:33:44:55 │ │
│ └─────────────────┴─────────────────┘ │
├─────────────────────────────────────────────────┤
│ IP-Paket (unverändert) │
├─────────────────────────────────────────────────┤
│ FCS (Frame Check Sequence / Prüfsumme) │
└─────────────────────────────────────────────────┘
Wichtig: Destination MAC = Router, nicht Server!
Woher kennt dein Laptop die Router-MAC?
ARP – Address Resolution Protocol
Laptop (Broadcast):
"Wer hat die IP 192.168.1.1? Sag mir deine MAC!"
Router:
"Das bin ich! Meine MAC ist 11:22:33:44:55:66"
Das passiert automatisch. Die Info wird gecached.
Layer 1: Physical
Frame wird zu Bits – Bits werden zu Signalen:
| Medium | Signal |
|---|---|
| Kupferkabel | Spannung: High/Low |
| Glasfaser | Licht: An/Aus |
| WLAN | Funkwellen |
01001000 01010100 01010100 01010000 ...
Ab hier übernimmt die Physik.
Die Reise durch das Netz
Hop für Hop
Der erste Hop: Dein Router
Laptop → [Frame] → Router
Der Router empfängt:
- Layer 1: Signale → Bits
- Layer 2: Frame prüfen. MAC okay? → Auspacken
- Layer 3: IP lesen. "212.132.79.37 – nicht mein Netz"
Routing-Entscheidung: "Ich schicke es Richtung Internet."
Der Router verpackt NEU
┌─────────────────────────────────────────────────┐
│ Ethernet-Header (NEU!) │
│ ┌─────────────────┬─────────────────┐ │
│ │ Source MAC │ Destination MAC │ │
│ │ Router-MAC │ Nächster-Router │ │
│ └─────────────────┴─────────────────┘ │
├─────────────────────────────────────────────────┤
│ IP-Paket (UNVERÄNDERT) │
│ Source: 141.62.xxx.xxx │
│ Dest: 212.132.79.37 │
└─────────────────────────────────────────────────┘
IP bleibt gleich. MAC ändert sich.
Mehrere Hops
Dein Laptop
↓ [Frame an Router 1]
Router HdM-Netz
↓ [Frame an Router 2]
Router BelWü
↓ [Frame an Router 3]
...
↓ [Frame an Server]
Webserver der HdM
Bei jedem Hop: Auspacken bis Layer 3, Routing, neu verpacken.
Die Ankunft
Der Server empfängt und antwortet
Decapsulation am Server
Bits empfangen (Layer 1)
↓
Frame prüfen: MAC okay? FCS okay? → Auspacken (Layer 2)
↓
IP lesen: Ziel-IP = meine IP? Ja! → Auspacken (Layer 3)
↓
TCP lesen: Port 443, Seq-Nr passt → Auspacken (Layer 4)
↓
HTTP lesen: "GET / HTTP/1.1" (Layer 7)
Der Webserver versteht: "Jemand will die Startseite."
Der Server antwortet
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 45231
<!DOCTYPE html>
<html lang="de">
<head>
<title>HdM Stuttgart</title>
...
~45 KB HTML müssen jetzt zu dir.
Encapsulation beim Server
Der Server macht dasselbe – nur in die andere Richtung:
HTTP-Response: "HTTP/1.1 200 OK..."
↓
TCP: Dest-Port: 52431 (dein Browser!)
↓
IP: Dest-IP: 141.62.xxx.xxx (dein Laptop!)
↓
Ethernet: Dest-MAC: Router des Server-Netzes
↓
Bits
Die Antwort reist zurück
Server
↓
Router → Router → Router → ...
↓
Router HdM
↓
Dein Laptop
Gleiches Spiel: Hop für Hop, IP bleibt gleich, MAC ändert sich.
Decapsulation bei dir
Bits empfangen
↓
Frame: MAC = meine MAC? → Auspacken
↓
IP: Ziel-IP = meine IP? → Auspacken
↓
TCP: Port 52431 = mein Browser → Auspacken
↓
HTTP: "HTTP/1.1 200 OK..."
↓
Browser rendert die Seite
Exkurse
TCP vs. UDP, MTU, HTTP-Methoden
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 |
Warum UDP bei Video-Calls?
Szenario: Ein Paket geht verloren.
| TCP | UDP |
|---|---|
| Warten... neu anfordern... warten... | Ignorieren, nächstes Frame zeigen |
| Video friert ein | Kurzes Artefakt |
Bei Echtzeit ist Verzögerung schlimmer als Verlust.
MTU & Fragmentierung
MTU = Maximum Transmission Unit
Ethernet-Frame kann maximal 1500 Bytes Nutzdaten transportieren.
Problem: Ein Foto hat 3.000.000 Bytes.
Lösung: TCP zerschneidet die Daten in ~2000 Segmente. Jedes Segment hat eine Sequenznummer. Der Empfänger setzt sie zusammen.
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 |
GET /index.html HTTP/1.1
POST /login HTTP/1.1
HTTP Status-Codes
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) |
Zusammenfassung Teil 1
Der Ablauf:
- DNS (UDP:53) → Name zu IP
- TCP-Handshake (SYN → SYN-ACK → ACK)
- HTTP-Request (GET /...)
- 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
Werkzeuge zum Selbst-Erkunden
Im Browser (F12 → Network-Tab):
- Jeder Request sichtbar
- Timing, Headers, Response
Im Terminal:
ping hdm-stuttgart.de # Latenz messen
traceroute hdm-stuttgart.de # Route anzeigen (Mac/Linux)
tracert hdm-stuttgart.de # Route anzeigen (Windows)
nslookup hdm-stuttgart.de # DNS abfragen
curl -I hdm-stuttgart.de # HTTP-Header abrufen
Pause
Danach: CSS
Teil 2: CSS
Webseiten gestalten
Was ist CSS?
Cascading Style Sheets
p {
color: blue;
font-size: 16px;
}
- Trennt Inhalt (HTML) von Darstellung (CSS)
- "Cascading" = Regeln können überschrieben werden
- Eine CSS-Datei kann viele HTML-Seiten stylen
CSS einbinden
Option 1: Externe Datei ✓
<link rel="stylesheet" href="style.css">
Option 2: Style-Tag
<style>p { color: blue; }</style>
Option 3: Inline ✗
<p style="color: blue;">...</p>
CSS-Anatomie
selector {
property: value;
}
Beispiel:
h1 {
color: #333333;
font-size: 2rem;
margin-bottom: 1rem;
}
Selektor → was wird gestylt Property → welche Eigenschaft Value → welcher Wert
Selektoren: Element
/* Alle <p>-Elemente */
p {
color: gray;
}
/* Mehrere Elemente gleichzeitig */
h1, h2, h3 {
font-family: sans-serif;
}
Element-Selektoren sind die einfachsten.
Selektoren: Klasse
<p class="wichtig">Dieser Text ist wichtig.</p>
<p>Dieser nicht.</p>
.wichtig {
color: red;
font-weight: bold;
}
Punkt vor dem Namen = Klasse
Selektoren: ID
<nav id="hauptnavigation">...</nav>
#hauptnavigation {
background: #333;
padding: 1rem;
}
Raute vor dem Namen = ID
⚠️ IDs sollten einmalig pro Seite sein.
Selektoren: Kombinationen
/* Nachfahre (beliebig tief verschachtelt) */
article p { line-height: 1.6; }
/* Direktes Kind (nur eine Ebene) */
nav > a { text-decoration: none; }
/* Nächstes Geschwister */
h2 + p { font-size: 1.2rem; }
/* Element mit Klasse */
p.wichtig { color: red; }
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 |
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 */
Box-Modell
┌─────────────────────────────────────┐
│ margin │
│ ┌─────────────────────────────┐ │
│ │ border │ │
│ │ ┌─────────────────────┐ │ │
│ │ │ padding │ │ │
│ │ │ ┌─────────────┐ │ │ │
│ │ │ │ content │ │ │ │
│ │ │ └─────────────┘ │ │ │
│ │ └─────────────────────┘ │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
Jedes Element ist eine Box.
Box-Modell: CSS
.box {
width: 200px;
height: 100px;
padding: 20px;
border: 2px solid black;
margin: 10px;
}
Wichtig:
box-sizing: border-box;
→ width/height inkludiert padding + border
Farben
/* Keyword */
color: red;
color: rebeccapurple;
/* Hex */
color: #FF0000;
color: #F00;
/* RGB / RGBA */
color: rgb(255, 0, 0);
color: rgba(255, 0, 0, 0.5);
/* HSL */
color: hsl(0, 100%, 50%);
Einheiten
| Einheit | Bedeutung |
|---|---|
px |
Pixel (absolut) |
% |
Prozent vom Elternelement |
em |
Relativ zur Schriftgröße des Elements |
rem |
Relativ zur Schriftgröße des Root-Elements |
vw / vh |
Prozent der Viewport-Breite/-Höhe |
Empfehlung:
rem für Schrift, % oder vw/vh für Layout
Pseudo-Klassen
/* Hover – Maus drüber */
a:hover { color: red; }
/* Besuchter Link */
a:visited { color: purple; }
/* Fokussiertes Element */
input:focus { border-color: blue; }
/* Erstes/n-tes Kind */
li:first-child { font-weight: bold; }
li:nth-child(odd) { background: #eee; }
: vor dem Namen = Pseudo-Klasse
Pseudo-Elemente
/* Vor dem Inhalt einfügen */
.required::before {
content: "* ";
color: red;
}
/* Erster Buchstabe */
p::first-letter {
font-size: 2em;
}
:: = Pseudo-Element (erzeugt "virtuelles" Element)
: = Pseudo-Klasse (wählt existierendes Element im Zustand)
Responsive Design
/* Mobile First: Basis-Styles */
.container {
padding: 1rem;
}
/* Ab 768px (Tablet): Anpassungen */
@media (min-width: 768px) {
.container {
padding: 2rem;
max-width: 720px;
}
}
/* Ab 1024px (Desktop): Weitere Anpassungen */
@media (min-width: 1024px) {
.container {
max-width: 960px;
}
}
Zusammenfassung CSS
Selektoren:
- Element:
p - Klasse:
.wichtig - ID:
#header - Kombinationen:
nav > a,h2 + p
Box-Modell: content → padding → border → margin
Spezifität: Inline > ID > Klasse > Element
Einheiten: rem für Text, %, vw/vh für Layout
Fragen & Diskussion
Nächster Termin: 24.01.2026 – JavaScript
Kontakt: lb-czechowski@hdm-stuttgart.de
Lizenz
Diese Präsentation ist lizenziert unter Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
Basiert auf Material von:
- Markus Thamm / Wolfgang Gruel (HdM Stuttgart)
- Michael Czechowski
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/

