public/uni
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2755d4dee06ed2fd28d58e0b41741bff670a927a
uni/courses/223015c/slides/2026-01-10-termin-2-netzwerke-protokolle-css.md

32 KiB
Raw Blame History

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
<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>

bg fit opacity:0.2

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/

bg fit

Termin 2 – 10.01.2026

Netzwerke, Protokolle & CSS

Agenda

Teil 1: Die Reise eines Klicks

  • Warum ist Netzwerk-Kommunikation kompliziert?
  • Was passiert, wenn du eine URL aufrufst?
  • DNS → TCP → HTTP → Response

Teil 2: CSS

  • Grundlagen, Selektoren, Spezifität
  • Box-Modell, Farben, Einheiten

Ressourcen zum Selbstlernen

Teil 1: Die Reise eines Klicks

Was passiert, wenn du www.hdm-stuttgart.de aufrufst?

Das Szenario

Du bist im WLAN der HdM angemeldest und gehst auf:

hdm-stuttgart.de

Zwischen Enter und der fertigen Seite: ~200 Millisekunden.

In dieser Zeit passieren hunderte Operationen.

Bevor wir sie durchgehen: Warum ist das überhaupt so kompliziert?

Das Grundproblem

Warum brauchen wir Schichten, Adressen, Ports?

Was zwischen dir und dem Server liegt

Du willst eine Webseite. Klingt einfach.

Aber dazwischen liegen:

  • Deine WLAN-Karte
  • Der Router im Flur
  • Das Netzwerk der HdM
  • Das Internet (dutzende Router)
  • Der Webserver in Vaihingen

Jede Station spricht eine andere "Sprache":

  • Dein Browser spricht HTTP ("Gib mir /index.html")
  • Das Kabel versteht nur Strom an/aus

Die Lösung: Aufgabenteilung

Statt dass jedes Programm alles können muss, teilen wir die Arbeit auf:

Wer Kümmert sich um
HTTP "Was will ich?" (Webseite, Bild, Video)
TCP "Kommt alles an? In der richtigen Reihenfolge?"
IP "Wo muss es hin?" (welcher Rechner im Internet)
Ethernet "Wie kommt es zum nächsten Gerät?"
Physik "Strom oder Licht durch das Kabel"

Jeder macht seinen Job. Keiner muss wissen, wie die anderen arbeiten.

Warum ist das clever?

Ohne Schichten: Dein Browser müsste wissen, wie man Ethernet-Frames baut, wie WLAN-Frequenzen funktionieren, wie Router Pakete weiterleiten...

Mit Schichten: Dein Browser sagt nur: "Ich will diese Seite." Alles andere übernehmen die Schichten darunter.

Das Prinzip heißt Abstraktion: Jede Schicht versteckt ihre Komplexität vor den anderen.

Warum brauchen wir IP-Adressen?

Das Internet ist kein einzelnes Netzwerk

Das Internet besteht aus tausenden separaten Netzwerken:

  • Netzwerk der HdM
  • Netzwerk der Telekom
  • Netzwerk von Google
  • Netzwerk deines Heimrouters
  • ...

Ein Paket muss von Netzwerk zu Netzwerk weitergereicht werden.

Router entscheiden bei jedem Hop: "In welches Netzwerk als nächstes?"

IP-Adressen = Globale Adressen

141.62.xxx.xxx    ← HdM-Netzwerk
212.132.79.37     ← Ziel-Server

Die IP-Adresse sagt dem Router:

  1. In welchem Netzwerk ist der Rechner?
  2. Welcher Rechner in diesem Netzwerk?

"141.62... ist nicht bei mir. Ich schicke das Paket Richtung eduroam."

Die IP-Adresse bleibt auf dem gesamten Weg gleich. Sie ist die Empfängeradresse auf dem Brief.

Warum reicht die MAC-Adresse nicht?

Jede Netzwerkkarte hat eine MAC-Adresse (z.B. aa:bb:cc:dd:ee:ff).

Problem: MAC funktioniert nur lokal.

  • Dein Laptop kennt die MAC deines Routers
  • Dein Router kennt die MAC des nächsten Routers
  • Aber niemand kennt die MAC des Webservers in Vaihingen

MAC = "Wer ist mein direkter Nachbar?" IP = "Wo ist das Ziel im gesamten Internet?"

Deshalb brauchen wir beides.

Warum brauchen wir Ports?

Ein Rechner, viele Programme

Dein Laptop hat eine IP-Adresse.

Aber gleichzeitig laufen:

  • Browser
  • Mail-Programm
  • Spotify
  • Discord
  • System-Updates

Ein Paket kommt an. Für welches Programm ist es?

Ports = Türnummern

IP-Adresse = Hausnummer      →  "Friedrichstraße 10"
Port       = Wohnungstür     →  "3. Stock links"

Jedes Programm "lauscht" auf einem Port:

Port Dienst
80 HTTP (Webseiten)
443 HTTPS (Webseiten, verschlüsselt)
25 SMTP (E-Mail senden)
22 SSH (Terminal)

Beide Seiten haben Ports

Dein Laptop:    141.62.xxx.xxx:52431
                              └─────── Dein Browser lauscht hier

Server:         212.132.79.37:443
                             └─────── Webserver lauscht hier

52431 ist ein zufälliger Port, den dein System für diese Verbindung vergeben hat.

Die Antwort des Servers geht an 141.62.xxx.xxx:52431 – und landet bei deinem Browser, nicht bei Spotify.

Zusammenfassung: Die Bausteine

Was wir jetzt wissen

Konzept Löst welches Problem?
Schichten Komplexität aufteilen, Abstraktion
IP-Adresse Ziel im globalen Internet finden
MAC-Adresse Nächsten Nachbarn im lokalen Netz finden
Port Richtiges Programm auf dem Rechner finden

Mit diesen Bausteinen können wir jetzt die Reise eines Klicks verfolgen.

Die Reise beginnt

Schritt für Schritt

Die Zeitlinie

[0 ms]    DNS-Anfrage: "Welche IP hat www.hdm-stuttgart.de?"
          ↓
[~20 ms]  DNS-Antwort: "212.132.79.37"
          ↓
[~25 ms]  TCP-Handshake: Verbindung aufbauen
          ↓
[~50 ms]  HTTP-Request: "GET /index.html"
          ↓
[~150 ms] HTTP-Response: Der HTML-Code kommt zurück
          ↓
[~200 ms] Browser rendert die Seite

Jeder dieser Schritte durchläuft alle Schichten – runter und wieder rauf.

Schritt 1: DNS

"Wo wohnt hdm-stuttgart.de?"

Das Problem

Dein Browser kennt nur den Namen: www.hdm-stuttgart.de

Das Internet kennt nur Zahlen: 212.132.79.37

Jemand muss übersetzen.

DNS: Das Telefonbuch des Internets

Domain Name System

Dein Laptop fragt sich durch eine Hierarchie:

  1. Browser-Cache: "War ich da kürzlich?" → Nein
  2. Betriebssystem-Cache: "Kennt Windows/Mac die IP?" → Nein
  3. Router / ISP: "Frag den DNS-Server deines Providers"

Wenn auch der Provider es nicht weiß, beginnt die rekursive Suche.

Die DNS-Hierarchie

                    . (Root)
                   /|\
                  / | \
               .de .com .org
               /
        hdm-stuttgart
             |
            www

Jede Ebene kennt nur die nächste Ebene darunter.

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 ein Netzwerk-Request

Die DNS-Anfrage ist nicht magisch. Sie ist selbst ein Paket, das durch alle Schichten muss:

Eigenschaft Wert
Protokoll UDP
Port 53
Inhalt "A-Record für www.hdm-stuttgart.de?"

Das DNS-Paket macht die gleiche Reise wie später der HTTP-Request – nur zu einem anderen Ziel.

Nach dem DNS-Lookup

Ergebnis: Dein Browser weiß jetzt:

www.hdm-stuttgart.de = 212.132.79.37

Diese Information wird gecached.

Nächster Schritt: Verbindung zum Server aufbauen.

Schritt 2: TCP-Handshake

"Hallo Server, bist du da?"

Warum ein Handshake?

HTTP läuft über TCP (Transmission Control Protocol).

TCP ist verbindungsorientiert: Bevor Daten fließen, müssen sich beide Seiten einig sein, dass sie miteinander reden wollen.

Analogie: Du rufst jemanden an. Das Telefon klingelt. Die Person nimmt ab. Erst dann redest du.

Der 3-Way-Handshake

Dein Laptop                              HdM-Server
    |                                        |
    |-------- SYN (Seq=1000) --------------->|
    |         "Ich will reden"               |
    |                                        |
    |<--- SYN-ACK (Seq=5000, Ack=1001) ------|
    |     "OK, ich auch"                     |
    |                                        |
    |-------- ACK (Ack=5001) --------------->|
    |         "Gut, dann los"                |
    |                                        |
    |        [ Verbindung steht ]            |

SYN = Synchronize · ACK = Acknowledge

Warum die Sequenznummern?

Problem: Pakete können im Internet:

  • Verloren gehen
  • Doppelt ankommen
  • In falscher Reihenfolge ankommen

Lösung: Jedes Byte wird nummeriert.

Der Empfänger weiß genau, welches Byte als nächstes kommen muss – und kann fehlende Pakete erneut anfordern.

Nach dem Handshake

Status: Die TCP-Verbindung steht.

Dein Laptop ←————————————————→ 212.132.79.37:443
   (Port 52431)                    (Port 443)

Jetzt erst kann der eigentliche HTTP-Request gesendet werden.

Schritt 3: Der 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

Das sind ~200 Bytes Text.

Aber diese 200 Bytes müssen durch das halbe Internet.

Wie?

Die Verpackungsstraße

Encapsulation: Schicht für Schicht

Jede Schicht verpackt

HTTP-Request: "GET / HTTP/1.1..."
    ↓
TCP packt ein:  [ Ports + Seq-Nr ] + HTTP-Request
    = Segment
    ↓
IP packt ein:   [ IP-Adressen ] + Segment
    = Paket
    ↓
Ethernet packt: [ MAC-Adressen ] + Paket + [ Prüfsumme ]
    = Frame
    ↓
Physik:         01001000 01010100 01010100 01010000 ...
    = Bits auf dem Kabel

Layer 4: Transport (TCP)

Der HTTP-Request wird zum Segment.

┌─────────────────────────────────────────────────┐
│ TCP-Header                                      │
│ ┌─────────────┬─────────────┬─────────────────┐ │
│ │ Source Port │ Dest Port   │ Sequence Number │ │
│ │ 52431       │ 443         │ 1001            │ │
│ └─────────────┴─────────────┴─────────────────┘ │
├─────────────────────────────────────────────────┤
│ Payload: "GET / HTTP/1.1..."                    │
└─────────────────────────────────────────────────┘

Neu hinzugekommen: Ports (wer sendet? wer empfängt?) und Sequenznummer

Layer 3: Network (IP)

Das Segment wird zum Paket.

┌─────────────────────────────────────────────────┐
│ IP-Header                                       │
│ ┌─────────────────┬─────────────────┐           │
│ │ Source IP       │ Destination IP  │           │
│ │ 141.62.xxx.xxx  │ 212.132.79.37   │           │
│ └─────────────────┴─────────────────┘           │
├─────────────────────────────────────────────────┤
│ TCP-Segment (von oben)                          │
└─────────────────────────────────────────────────┘

Neu: IP-Adressen – woher kommt das Paket, wohin soll es?

Layer 2: Data Link (Ethernet)

Das Paket wird zum Frame.

┌─────────────────────────────────────────────────┐
│ Ethernet-Header                                 │
│ ┌─────────────────┬─────────────────┐           │
│ │ Source MAC      │ Destination MAC │           │
│ │ aa:bb:cc:dd:ee  │ 11:22:33:44:55  │           │
│ └─────────────────┴─────────────────┘           │
├─────────────────────────────────────────────────┤
│ IP-Paket (von oben)                             │
├─────────────────────────────────────────────────┤
│ FCS (Prüfsumme)                                 │
└─────────────────────────────────────────────────┘

Neu: MAC-Adressen – aber Achtung: Das ist die MAC des Routers, nicht des Servers!

Layer 1: Physical

Der Frame wird zu Bits – und die Bits zu physikalischen Signalen.

Medium Signal
Kupferkabel Spannung: High/Low
Glasfaser Licht: An/Aus
WLAN Funkwellen 
01001000 01010100 01010100 01010000 ...

Ab hier übernimmt die Physik.

MAC vs. IP – nochmal genau

IP-Adresse MAC-Adresse
Frage Wer ist das Endziel? Wer ist der nächste Hop?
Reichweite Global (ganzes Internet) Lokal (bis zum nächsten Router)
Ändert sich? Nein, bleibt gleich Ja, bei jedem Hop
Analogie Empfänger auf dem Brief "Nächstes Postamt: XY"

Die MAC-Adresse im ersten Frame ist die MAC des Routers – nicht des Servers!

Woher kennt dein Laptop die MAC des Routers?

ARP – Address Resolution Protocol

Dein Laptop (Broadcast an alle):
    "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"

Diese Information wird gecached.

Die Reise durch das Netz

Hop für Hop

Der erste Hop: Dein Router

Dein Laptop → [Frame] → Router

Der Router empfängt den Frame:

  1. Layer 1: Signale → Bits
  2. Layer 2: Prüft Frame. "MAC stimmt, FCS okay" → Auspacken
  3. Layer 3: Liest IP-Header. "212.132.79.37 – nicht mein Netz"

Routing-Entscheidung: "Ich schicke es Richtung eduroam."

Der Router verpackt NEU

Der Router erstellt einen neuen Frame für den nächsten Hop:

┌─────────────────────────────────────────────────┐
│ 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                             │
└─────────────────────────────────────────────────┘

Die IP bleibt gleich. Die MAC ändert sich.

Mehrere Hops

Dein Laptop
    ↓ [Frame mit MAC des HdM-Routers]
Router (HdM-Netz)
    ↓ [Frame mit MAC des eduroam-Routers]
Router (BelWü)
    ↓ [Frame mit MAC des nächsten Routers]
...weitere Router...
    ↓ [Frame mit MAC des Ziel-Servers]
Webserver der HdM

Bei jedem Hop: Auspacken bis Layer 3, Routing-Entscheidung, neu verpacken.

Die Ankunft

Decapsulation am Server

Der Server empfängt

Am Webserver passiert alles rückwärts (Decapsulation):

Bits empfangen (Layer 1)
    ↓
Frame prüfen: MAC korrekt? FCS okay? → Auspacken (Layer 2)
    ↓
IP-Paket lesen: Ziel-IP = meine IP? Ja! → Auspacken (Layer 3)
    ↓
TCP-Segment lesen: Port 443, Seq-Nr passt → Auspacken (Layer 4)
    ↓
HTTP-Request lesen: "GET / HTTP/1.1" (Layer 7)

Der Webserver versteht: "Jemand will die Startseite."

Die Antwort

Der gleiche Weg zurück

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>
...

Diese ~45 KB HTML müssen jetzt zu dir.

Encapsulation beim Server

Der Server macht dasselbe wie du vorher – nur in die andere Richtung:

HTTP-Response: "HTTP/1.1 200 OK..."
    ↓
TCP packt ein:  [ Ports + Seq-Nr ] + Response
    Dest-Port: 52431 (dein Browser!)
    ↓
IP packt ein:   [ IP-Adressen ]
    Dest-IP: 141.62.xxx.xxx (dein Laptop!)
    ↓
Ethernet packt: [ MAC-Adressen ]
    Dest-MAC: Router des Server-Netzes
    ↓
Bits auf dem Kabel

Die Antwort reist zurück

Server
    ↓
Router (Ziel-Netz)
    ↓
...weitere Router...
    ↓
Router (HdM-Netz)
    ↓
Dein Laptop

Bei jedem Hop: Auspacken bis Layer 3, Routing-Entscheidung, neu verpacken.

Bis die Antwort bei dir ankommt – und dein Browser sie auspackt.

Decapsulation bei dir

Bits empfangen
    ↓
Frame: MAC = meine MAC? → Auspacken
    ↓
IP-Paket: Ziel-IP = meine IP? → Auspacken
    ↓
TCP-Segment: Port 52431 = mein Browser → Auspacken
    ↓
HTTP-Response: "HTTP/1.1 200 OK..."
    ↓
Browser rendert die Seite

Zusammenfassung

Das TCP/IP-Modell

Die Schichten (TCP/IP)

Schicht Name Dateneinheit Adressierung
4 Anwendung Daten –
3 Transport Segment Ports
2 Internet Paket IP-Adressen
1 Netzzugang Frame MAC-Adressen

4 Schichten. Das reicht, um das Internet zu verstehen.

OSI vs. TCP/IP

    OSI (Theorie)              TCP/IP (Praxis)
┌─────────────────┐        ┌─────────────────┐
│  7. Anwendung   │        │                 │
├─────────────────┤        │   Anwendung     │
│  6. Darstellung │        │                 │
├─────────────────┤        │                 │
│  5. Sitzung     │        │                 │
├─────────────────┤        ├─────────────────┤
│  4. Transport   │        │   Transport     │
├─────────────────┤        ├─────────────────┤
│  3. Vermittlung │        │   Internet      │
├─────────────────┤        ├─────────────────┤
│  2. Sicherung   │        │                 │
├─────────────────┤        │   Netzzugang    │
│  1. Bitübertrag │        │                 │
└─────────────────┘        └─────────────────┘

OSI ist ein Referenzmodell. TCP/IP ist die Realität.

Was ihr wissen solltet

Den Ablauf:

  1. DNS-Lookup (UDP:53) → IP-Adresse
  2. TCP-Handshake (SYN → SYN-ACK → ACK)
  3. HTTP-Request
  4. HTTP-Response

Die Konzepte:

  • IP bleibt gleich, MAC ändert sich pro Hop
  • Ports identifizieren Programme
  • Encapsulation/Decapsulation

Die Dateneinheiten (PDUs)

Schicht Dateneinheit Was kommt hinzu?
Anwendung Daten HTTP-Header
Transport Segment Ports, Seq-Nr
Internet Paket IP-Adressen
Netzzugang Frame MAC, Prüfsumme

Encapsulation: Jede Schicht verpackt die Daten der Schicht darüber. Decapsulation: Beim Empfang wird Schicht für Schicht ausgepackt.

Exkurs: MTU & Fragmentierung

Die MTU (Maximum Transmission Unit)

Ein Ethernet-Frame kann maximal 1500 Bytes Nutzdaten transportieren.

┌───────────┬──────────────────────────────────────────┬──────────┐
│ Header    │ Payload (max. 1500 Bytes)                │ Trailer  │
│ 14 Bytes  │                                          │ 4 Bytes  │
└───────────┴──────────────────────────────────────────┴──────────┘

Problem: Ein Foto hat 3.000.000 Bytes. Lösung: TCP zerschneidet die Daten in ~2000 Segmente.

TCP sorgt für Ordnung

Jedes Segment hat eine Sequenznummer.

Segment 1: Bytes 0-1459      Seq=0
Segment 2: Bytes 1460-2919   Seq=1460
Segment 3: Bytes 2920-4379   Seq=2920
...

Der Empfänger setzt die Segmente zusammen – auch wenn sie in falscher Reihenfolge ankommen.

Exkurs: TCP vs. UDP

Zwei Transport-Protokolle

TCP UDP
Verbindung Ja (Handshake) Nein
Reihenfolge garantiert Ja Nein
Fehlende Pakete Werden nachgefordert Gehen verloren
Geschwindigkeit Langsamer Schneller

Wann was?

TCP:

  • Web (HTTP/HTTPS)
  • E-Mail
  • Dateitransfer
  • SSH

→ Wenn jedes Byte ankommen muss

UDP:

  • DNS
  • Video-Streaming
  • Online-Gaming
  • Video-Calls

→ Wenn Geschwindigkeit wichtiger ist als Vollständigkeit

Warum UDP bei Video-Calls?

Szenario: Ein Paket geht verloren.

TCP: Wartet, fordert neu an, wartet... → Video friert ein

UDP: Ignoriert es, zeigt nächstes Frame → Kurzes Artefakt

Bei Echtzeit ist ein verlorenes Frame weniger schlimm als Verzögerung.

HTTP-Response & Status-Codes

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>

Status-Codes:

  • 2xx Erfolg (200 OK)
  • 3xx Umleitung (301 Moved)
  • 4xx Client-Fehler (404 Not Found)
  • 5xx Server-Fehler (500 Internal Error)

HTTP-Methoden

Methode Zweck Beispiel
GET Daten abrufen Seite laden
POST Daten senden Formular absenden
PUT Daten ersetzen Profil aktualisieren
DELETE Daten löschen Account löschen

Werkzeuge zum Selbst-Erkunden

Im Browser (F12 → Network-Tab):

  • Jeder Request sichtbar
  • Timing, Headers, Response

Im Terminal:

ping hdm-stuttgart.de
traceroute hdm-stuttgart.de
nslookup hdm-stuttgart.de
curl -I hdm-stuttgart.de

Teil 2: CSS

Webseiten gestalten

Was ist CSS?

Cascading Style Sheets

  • Trennt Inhalt (HTML) von Darstellung (CSS)
  • "Cascading" = Regeln können überschrieben werden
  • Eine CSS-Datei für viele HTML-Seiten
p {
    color: blue;
    font-size: 16px;
}

CSS einbinden

Option 1: Externe Datei (empfohlen)

<link rel="stylesheet" href="style.css">

Option 2: Style-Tag

<style>p { color: blue; }</style>

Option 3: Inline (vermeiden)

<p style="color: blue;">...</p>

CSS-Anatomie

selector {
    property: value;
}

Beispiel:

h1 {
    color: #333333;
    font-size: 2rem;
    margin-bottom: 1rem;
}

Selektoren: Element

/* Alle <p>-Elemente */
p {
    color: gray;
}

/* Mehrere Elemente */
h1, h2, h3 {
    font-family: sans-serif;
}

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) */
article p { line-height: 1.6; }

/* Direktes Kind */
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 */

Box-Modell

┌─────────────────────────────────────┐
│              margin                 │
│   ┌─────────────────────────────┐   │
│   │          border             │   │
│   │   ┌─────────────────────┐   │   │
│   │   │       padding       │   │   │
│   │   │   ┌─────────────┐   │   │   │
│   │   │   │   content   │   │   │   │
│   │   │   └─────────────┘   │   │   │
│   │   └─────────────────────┘   │   │
│   └─────────────────────────────┘   │
└─────────────────────────────────────┘

Box-Modell: CSS

.box {
    width: 200px;
    height: 100px;
    padding: 20px;
    border: 2px solid black;
    margin: 10px;
    
    /* Wichtig: */
    box-sizing: border-box;
}

box-sizing: border-box → width inkl. padding + border

Farben

/* Keyword */
color: red;

/* 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 Parent
em Relativ zur Schriftgröße
rem Relativ zur Root-Schriftgröße
vw/vh Viewport-Breite/-Höhe

Empfehlung: rem für Schrift, % oder vw/vh für Layout

Pseudo-Klassen

a:hover { color: red; }
a:visited { color: purple; }
input:focus { border-color: blue; }

li:first-child { font-weight: bold; }
li:nth-child(odd) { background: #eee; }

Pseudo-Elemente

.required::before {
    content: "* ";
    color: red;
}

p::first-letter { font-size: 2em; }

: = Pseudo-Klasse · :: = Pseudo-Element

Responsive Design

/* Mobile First */
.container { padding: 1rem; }

/* Ab 768px (Tablet) */
@media (min-width: 768px) {
    .container { 
        padding: 2rem; 
        max-width: 720px; 
    }
}

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/