hdm/2025

Files

T

libretechandClaude Opus 4.5 c35541961e add archive directory with old klausurfragen files

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

2026-02-02 13:42:12 +01:00

22 KiB

Raw Blame History

Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.

223015c – Grundlagen IT- und Internettechnik

WS 2025/26 – Michael Czechowski – HdM Stuttgart 40 Punkte / 40 Minuten

Q1 – Von-Neumann: Komponenten zuordnen (3 pt)

Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.

Rechenwerk (ALU): Führt arithmetische und logische Operationen durch.
Steuerwerk: Holt, dekodiert und steuert die Ausführung von Befehlen.
Speicherwerk: Enthält sowohl Programme als auch Daten (Stored Program Concept).
Ein-/Ausgabe: Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.
Bus-System: Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.

Feedback: Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).

Q2 – Von-Neumann vs. Harvard (2 pt)

Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.

Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?

Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität. ✅
Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.

Feedback: Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.

Q3 – Stored Program Concept (2 pt)

Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.

Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.

Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich. ✅
Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.

Feedback: Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.

Q4 – HTML: `<head>` vs. `<body>` (2 pt)

Ein Student erstellt eine Webseite und platziert alles im <body> – auch den <title> und die <meta name="description">.

Welche zwei konkreten Konsequenzen hat das?

Kein Problem – Browser ignorieren die Unterscheidung zwischen <head> und <body>.
(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen. ✅
(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
Nur das Fehlen von <meta charset> ist ein Problem – title und description funktionieren überall.

Feedback: title und meta description gehören in <head>. Im <body>: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.

Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)

Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich allen zugute kommt.

Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.

Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann. ✅
Dark Mode: Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.

Feedback: Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.

Q6 – European Accessibility Act (2 pt)

Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.

Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?

Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich. ✅
Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.

Feedback: EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.

Q7 – TCP/IP: Protokoll → Schicht (3 pt)

Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.

HTTP: Anwendung
DNS: Anwendung
TCP: Transport
UDP: Transport
IP: Internet
Ethernet: Netzzugang

Feedback: Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.

Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)

Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.

Daten: Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).
Segment: Transportschicht – Daten + Ports und Sequenznummern.
Paket: Internetschicht – Segment + IP-Adressen (Quelle und Ziel).
Frame: Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.

Feedback: Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.

Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)

Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.

Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?

Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop). ✅
Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.

Feedback: IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.

Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)

Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.

Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?

Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden. ✅
Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.

Feedback: Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).

Q11 – TCP vs. UDP: Videostreaming (2 pt)

Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.

Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?

UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter. ✅
TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.

Feedback: Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.

Q12 – HTTP-Methoden: Szenario (2 pt)

Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das alte Bild ersetzt.

Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?

GET – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet keine Daten zum Server. ✅
POST – POST ist immer für das Ersetzen von Daten zuständig.
DELETE – DELETE sendet das neue Foto und löscht gleichzeitig das alte.

Feedback: PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.

Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)

Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an: HTTP/1.1 503 Service Unavailable

Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?

Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen. ✅
Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.

Feedback: 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.

Q14 – DNS: Rolle im Ablauf (2 pt)

Du gibst https://hdm-stuttgart.de in die Adresszeile ein.

Was passiert vor dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?

Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
DNS-Auflösung: Der Name hdm-stuttgart.de wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen. ✅
DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.

Feedback: DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.

Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)

Gegeben folgender CSS-Code:

p           { color: blue; }      /* (A) */
.highlight  { color: green; }     /* (B) */
#main       { color: red; }       /* (C) */

Ein Element <p class="highlight" id="main">Text</p> wird angezeigt. Welche Farbe zeigt der Text an, und warum?

Blau – die Element-Regel steht zuerst im Code und hat daher Vorrang.
Grün – Klassen-Selektoren haben immer Vorrang vor IDs.
Rot – die ID-Regel #main hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1). ✅
Rot – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.

Feedback: Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.

Q16 – Responsive Design: Mobile First (2 pt)

Ein Developer schreibt folgendes CSS:

.container { background: white; }

@media (min-width: 768px) {
    .container { background: blue; }
}

@media (min-width: 1024px) {
    .container { background: green; }
}

Welche Farbe hat .container bei einem Bildschirm von 900 px Breite, und warum?

Weiß – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
Grün – die letzte Media-Query überschreibt immer alle vorherigen.
Blau – bei 900 px greift min-width: 768px (900 ≥ 768), aber min-width: 1024px greift nicht (900 < 1024). ✅
Weiß – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.

Feedback: Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.

Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)

Du gibst eine URL ein. Welche Reihenfolge der Schritte ist korrekt?

(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK ✅
(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK

Feedback: Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).

Q18 – Bonusfrage: Spezifität Edge Case (1 pt)

Es gibt zwei CSS-Regeln für ein <p>-Element:

p p p p p p p p p p  { color: blue; }   /* 100× Element-Selektor */
.highlight           { color: red; }    /* 1× Klasse */

Das Element hat die Klasse highlight. Welche Farbe gewinnt?

Blau – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren. ✅
Blau – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
Unentschieden – die Regeln haben exakt gleiche Spezifität.

Feedback: Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.

Q19 – Von-Neumann: Der Flaschenhals (Engpass)

Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?

Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden. ✅
Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.

Feedback: Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.

Q20 – HTML: Encoding (Charset)

In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im <head> ist <meta charset="UTF-8">. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?

Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät. ✅
Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.

Feedback: Ohne definierte charset (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.

Q21 – Barrierefreiheit: POUR-Prinzip

Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?

Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar. ✅
Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
Die Webseite stürzt in alten Browsern ab.

Feedback: „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).

Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)

In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header entfernt?

Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten. ✅
Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)

Feedback: Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).

Q23 – Ports: Wozu genau?

Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?

Sie bestimmt die Geschwindigkeit der Verbindung.
Sie dient zur Verschlüsselung der Daten.
Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver). ✅
Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.

Feedback: Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).

Q24 – TCP: Sequenznummern

TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?

Sie verhindern, dass Hacker die Verbindung abhören können.
Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger. ✅
Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
Sie bestimmen die maximale Größe einer Datei.

Feedback: Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.

Q25 – HTTP Methoden: Sicherheit

Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?

GET ist langsamer als POST und Passwörter müssen schnell übertragen werden.
Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST stehen sie im Body. ✅
GET erlaubt nur Zahlen, keine Buchstaben.
GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.

Feedback: Parameter bei GET hängen an der URL (?pw=123). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.

Q26 – HTTP Status: 404 Not Found

Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?

Der Server ist abgestürzt.
Das Internet ist ausgefallen.
Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link). ✅
Der DNS-Server konnte den Namen nicht auflösen.

Feedback: 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“

Q27 – CSS: `!important` vs. ID

In Q15 hat die ID gewonnen. Nun ändern wir den Code:

#main { color: red; }
p     { color: blue !important; }

Welche Farbe hat das <p id="main"> Element nun?

Rot – ID ist immer noch spezifischer als ein Element-Selektor.
Lila – Die Farben mischen sich.
Blau – !important durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
Rot – !important wird von modernen Browsern ignoriert.

Feedback: !important ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.

Q28 – Responsive Design: Desktop First

In Q16 nutzten wir min-width (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?

@media (device-width: small) { ... }
@media (min-width: ...) – das bleibt gleich, nur die Reihenfolge ändert sich.
@media (max-width: ...) – Wir definieren Stile für Bildschirme, die kleiner als eine bestimmte Breite sind. ✅
@media (mobile: true) { ... }

Feedback: Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit max-width (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).

22 KiB Raw Blame History Unescape Escape