` und die `<meta name="description">`.** **Welche zwei konkreten Konsequenzen hat das?** * [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`. * [x] **(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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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:** ```css p { color: blue; } /* (A) */ .highlight { color: green; } /* (B) */ #main { color: red; } /* (C) */ ``` **Ein Element `Text` 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. * [x] **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:** ```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. * [x] **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 * [x] **(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 ``-Element:** ```css 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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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:** ```css #main { color: red; } p { color: blue !important; } ``` **Welche Farbe hat das `` Element nun?** * [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor. * [ ] **Lila** – Die Farben mischen sich. * [x] **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. * [x] **`@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).

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. * [x] **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. * [x] **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: `` vs. `` (2 pt) **Ein Student erstellt eine Webseite und platziert *alles* im `` – auch den `` und die `<meta name="description">`.** **Welche zwei konkreten Konsequenzen hat das?** * [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`. * [x] **(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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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:** ```css p { color: blue; } /* (A) */ .highlight { color: green; } /* (B) */ #main { color: red; } /* (C) */ ``` **Ein Element `Text` 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. * [x] **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:** ```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. * [x] **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 * [x] **(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 ``-Element:** ```css 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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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. * [x] **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:** ```css #main { color: red; } p { color: blue !important; } ``` **Welche Farbe hat das `` Element nun?** * [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor. * [ ] **Lila** – Die Farben mischen sich. * [x] **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. * [x] **`@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).