HTML-Grundlagen

SAP Implementation Consulting & ERP - Startupistan Deutschland · Block I · Lernnotizen zur Wiederholung.

Wo HTML einzuordnen ist: die drei Sprachen des Webs

Fast jede Seite im Web ist aus drei Sprachen aufgebaut, und jede hat genau eine Aufgabe. Diese Aufteilung zuerst klar zu haben, macht alles Weitere einfacher - HTML versucht nie, gut auszusehen, und das ist Absicht.

Sprache	Ihre eine Aufgabe	Sagt Dinge wie
HTML	Struktur & Inhalt - was jedes Ding ist	”das ist eine Überschrift”, “das ist eine Liste”
CSS	Aussehen - wie es aussieht	”diese Überschrift ist dunkelgrün, in dieser Schrift”
JavaScript	Verhalten - was es tut	”wenn dieser Button geklickt wird, tue X”

Dieses Kapitel behandelt nur die erste Zeile. Das Web hält sie bewusst getrennt - die meiste andere Software mischt Struktur, Aussehen und Logik in einer einzigen Codebasis, aber das Web trennt sie, damit sich ein Design ändern lässt, ohne den Inhalt anzufassen, und damit Maschinen, die nur die Struktur lesen (Suchmaschinen, Screenreader), eine Seite verstehen können, ohne Code auszuführen.

Zwei Begriffe, die es sich jetzt zu definieren lohnt, weil sie durch alles hindurchlaufen:

Browser - das Programm, das diese drei Sprachen liest und die Seite darstellt (Chrome, Firefox, Edge, Safari). Er ist der universelle Client: einmal geschrieben, funktioniert eine Seite auf jedem Gerät, ohne dass etwas installiert werden muss.
Semantisch - “Bedeutung tragend”. Ein semantisches Element sagt, was sein Inhalt ist; ein nicht-semantisches sagt nichts. Diese Idee ist der rote Faden durch das ganze Kapitel.

Was HTML eigentlich ist

HTML = HyperText Markup Language. Zerlegen wir den Namen:

HyperText - Text, der Links zu anderem Text enthält. Links sind das, was aus getrennten Dokumenten ein zusammenhängendes Web gemacht hat.
Markup - das Auszeichnen von Inhalt mit Labels, die sagen, was jedes Stück ist. Die Labels sind nicht der Inhalt; sie sind Information über den Inhalt.
Language - es hat feste Regeln und ein festes Vokabular, auf das sich jeder Browser einigt, weshalb dieselbe Seite überall gleich dargestellt wird.

Die mit Abstand wichtigste Idee: HTML sagt, was Inhalt ist, nicht wie er aussieht. Wenn ich <h1>My Bakery</h1> schreibe, sage ich nicht “mach das groß” - ich sage “das ist die wichtigste Überschrift auf der Seite”. Der Browser entscheidet sich, sie standardmäßig groß darzustellen, und CSS kann sie später in jede beliebige Größe bringen, während sie die wichtigste Überschrift bleibt.

Dieselben Wörter mit drei verschiedenen Labels bedeuten für eine Maschine drei verschiedene Dinge:

<h1>Fresh bread every morning</h1>   <!-- die Hauptüberschrift der Seite -->
<p>Fresh bread every morning</p>      <!-- ein Textabsatz -->
<li>Fresh bread every morning</li>    <!-- ein Punkt in einer Liste -->

Identischer Text. Eine Suchmaschine gewichtet die h1-Wörter weit stärker als die p-Wörter, und ein Screenreader (Software, die eine Seite für Menschen vorliest, die sie nicht sehen können) behandelt jedes davon völlig anders. Ehrliches Labeln ist keine Pedanterie - es ist der Grund, warum die Seite für jeden Leser nutzbar bleibt, Mensch wie Maschine.

Anatomie eines HTML-Dokuments

Jede ordentliche HTML-Seite - vom fünfzeiligen Platzhalter bis zur weltweiten Zeitung - hat dasselbe vierteilige Skelett, in dieser Reihenfolge. Hier ist es, kommentiert:

<!DOCTYPE html>                <!-- 1. Deklaration: "lies das als modernes HTML" -->
<html lang="en">              <!-- 2. Wurzelelement, umschließt alles; lang = Sprache des Inhalts -->
  <head>                      <!-- 3. Infos ÜBER die Seite - auf der Seite nicht sichtbar -->
    <meta charset="UTF-8">     <!-- welches Alphabet die Datei verwendet (UTF-8 = alle Sprachen) -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Bakery</title>   <!-- erscheint im Browser-TAB, in Lesezeichen, in Suchergebnissen -->
  </head>
  <body>                      <!-- 4. Alles, was der Besucher tatsächlich SIEHT -->
    <h1>My Bakery</h1>
    <p>Fresh bread, honest coffee.</p>
  </body>
</html>

Die vier Teile, von oben nach unten:

Teil	Was es ist	Kernpunkt
`<!DOCTYPE html>`	Eine Deklaration, kein Element	Immer Zeile 1, immer genau diese Schreibweise, hat nie einen schließenden Partner
`<html>`	Die Wurzel, die alles umschließt	`lang="en"` benennt die Sprache - Screenreader & Übersetzung verlassen sich darauf
`<head>`	Infos über die Seite (Metadaten)	Nichts hiervon wird auf der Seite selbst dargestellt
`<body>`	Alles, was der Besucher sieht	Überschriften, Absätze, Bilder, Links leben alle hier

Elemente, Tags und Attribute

Drei Begriffe tauchen auf jeder Seite dieses Themas auf. Entwickler benutzen sie locker; Fehlermeldungen und Dokumentation benutzen sie präzise, also lerne ich sie präzise.

<p>

→

content

→

</p>

ein Element

Element - ein vollständiges Stück der Seite: das Markup plus seinem Inhalt. <p>Fresh bread</p> ist ein Element.
Tag - der Marker in spitzen Klammern, der ein Element öffnet oder schließt. <p> öffnet, </p> schließt; der Schrägstrich ist das, was es zu einem Schließer macht.
Attribute - ein name="value"-Paar innerhalb eines öffnenden Tags, das das Element konfiguriert. In <html lang="en"> ist der Name lang und der Wert "en".

Ein typisches Element liest sich also so: öffnendes Tag (evtl. mit Attributen) → Inhalt → schließendes Tag.

<p lang="de">Frisches Brot, ehrlicher Kaffee.</p>

Ein Element, zwei Tags, ein Attribut (lang="de", das nur diesen Absatz als Deutsch kennzeichnet), Inhalt in der Mitte.

Void elements tragen keinen Inhalt, also gibt es nichts zu schließen - kein schließendes Tag. Die zwei, die mir ständig begegnen, sind <meta> und <img>; alles, was sie brauchen, steht in Attributen. Void elements sind die Ausnahme; im Zweifel wird ein Element geschlossen.

Verschachtelung - Elemente enthalten Elemente (der body enthält das h1; das html enthält alles). Eine Regel bestimmt sie: das zuletzt geöffnete Element wird zuerst geschlossen. Kisten in Kisten, niemals überlappende Ringe.

<!-- FALSCH: strong wurde zuletzt geöffnet, aber p schließt zuerst - sie überlappen -->
<p>Our bread is <strong>baked fresh</p></strong>

<!-- RICHTIG: in umgekehrter Reihenfolge des Öffnens schließen -->
<p>Our bread is <strong>baked fresh</strong></p>

Einrückung (zwei Leerzeichen pro Ebene) ist rein für Menschen - der Browser ignoriert sie vollständig. Ich rücke ein, damit mein späteres Ich die Verschachtelung lesen kann.

Die Tag-Referenztabelle

Die meistgenutzten Tags, gruppiert. Das ist das Arbeitsvokabular für das ganze Kapitel - ich lerne es nicht auswendig, ich erkenne es wieder.

Überschriften & Text

Tag	Zweck	Beispiel
`<h1>`-`<h6>`	Abschnittstitel, nach Wichtigkeit gereiht (1 = oben)	`<h1>My Bakery</h1>`
`<p>`	Ein Textabsatz	`<p>Baked every morning.</p>`
`<strong>`	Inhalt, der ernsthaft wichtig ist	`Closes <strong>Thursday</strong>.`
`<em>`	Betonung in der Stimme, die die Bedeutung ändern kann	`We bake <em>everything</em>.`
`<br>`	Ein einzelner Zeilenumbruch (void)	`Line one<br>Line two`

Listen

Tag	Zweck	Beispiel
`<ul>`	Ungeordnete Liste - die Reihenfolge spielt keine Rolle	`<ul><li>Milk</li></ul>`
`<ol>`	Geordnete Liste - die Reihenfolge ist der Punkt	`<ol><li>Preheat</li></ol>`
`<li>`	Ein Punkt in einer der beiden Listenarten	`<li>Croissant</li>`

Links & Bilder

Tag	Zweck	Beispiel
`<a>`	Ein Link, der dorthin zeigt, wohin `href` sagt	`<a href="menu.html">Menu</a>`
`<img>`	Ein Bild (void), aus seinem `src`	`<img src="photo.png" alt="...">`

Struktur / semantische Container

Tag	Zweck	Beispiel
`<header>`	Einleitungsbereich - Seitenname & Navigation	`<header>…</header>`
`<nav>`	Die Navigationslinks selbst	`<nav>…</nav>`
`<main>`	Der einzigartige Inhalt dieser Seite (einer pro Seite)	`<main>…</main>`
`<section>`	Eine thematische Gruppe, meist mit eigener Überschrift	`<section>…</section>`
`<article>`	Ein in sich geschlossenes Stück (ein Beitrag, eine Karte)	`<article>…</article>`
`<footer>`	Abschlussbereich - Kleingedrucktes, nebensächliche Infos	`<footer>…</footer>`
`<div>`	Block-Container ohne Bedeutung (zum Gruppieren)	`<div>…</div>`
`<span>`	Inline-Container ohne Bedeutung (wenige Wörter)	`Price: <span>5.80</span>`

Tabellen & Formulare (volle Details in ihren eigenen Abschnitten unten)

Tag	Zweck	Beispiel
`<table>` `<tr>` `<th>` `<td>`	Raster / Zeile / Kopfzelle / Datenzelle	siehe Abschnitt Tabellen
`<form>`	Container für einen Satz Fragen + Absenden	`<form>…</form>`
`<label>` `<input>`	Feldname / das Feld selbst	`<label for="x">…`

Überschriften und Text-Semantik

Überschriften sind eine Gliederung, kein Schriftgrößen-Wähler

h1-h6 sind Ränge der Wichtigkeit, keine Größen. Zusammen bilden sie die Gliederung der Seite, wie die Kapitel und Abschnitte eines Buchs. Zwei Regeln halten die Gliederung ehrlich:

Ein <h1> pro Seite - es benennt, worum es auf der ganzen Seite geht. Zwei h1 = zwei Ansprüche auf denselben Thron.
Keine Ebenen überspringen - nach einem h2 gehst du zu h3, wenn du tiefer gehst, nicht direkt zu h4.

Browser stellen höhere Ebenen standardmäßig größer dar, was Anfänger verführt, eine Überschrift nach ihrer Größe zu wählen. Widersteh dem - CSS macht später jede Überschrift zu jeder Größe. Die Ebene ist eine Aussage über die Bedeutung, die jede Designänderung überdauert.

Absätze und das Zusammenfallen von Leerraum

<p> kennzeichnet einen Absatz. Die Überraschung, auf die jeder einmal stößt: der Browser lässt Leerraum zusammenfallen. Jede Folge von Leerzeichen, Tabs und Zeilenumbrüchen im Quelltext wird auf der Seite zu einem einzigen Leerzeichen. Fünfmal Enter zu drücken ändert nichts - nur ein neues <p> erzeugt einen neuen Absatz. Das ist befreiend: ich kann den Quelltext für die menschliche Lesbarkeit formatieren, und die dargestellte Seite bleibt davon unberührt.

strong vs. em - Bedeutung, nicht fett und kursiv

Beide sehen aus wie Stil-Schalter (Browser stellen strong standardmäßig fett und em kursiv dar), aber sie tragen Bedeutung:

<strong> - dieser Inhalt ist ernsthaft wichtig (eine Warnung, eine Frist, eine Kernaussage).
<em> - dieses Wort wird betont, so wie meine Stimme es laut betonen würde. “We bake <em>everything</em> ourselves” vs. “We bake everything <em>ourselves</em>” betonen mit denselben Wörtern verschiedene Aussagen.

Listen

Drei Elemente, und die Wahl zwischen ihnen ist eine Bedeutungs-Wahl wie alles in HTML:

<ul> - ungeordnete Liste (Reihenfolge spielt keine Rolle): eine Einkaufsliste.
<ol> - geordnete Liste (Reihenfolge ist der Punkt): Rezeptschritte.
<li> - ein Punkt, in beiden verwendet.

<ul>
  <li>Butter croissant</li>
  <li>Cinnamon roll</li>
</ul>

Strukturregel: die einzigen direkten Kinder, die ein ul oder ol haben darf, sind li-Elemente. Text und andere Elemente kommen in die Listenpunkte, niemals lose dazwischen.

Verschachtelte Listen bilden Kategorien - ein Listenpunkt kann eine ganze Liste enthalten, und so wird ein Menü mit Kategorien geformt:

<ul>
  <li>Breads
    <ul>
      <li>Country sourdough</li>
      <li>Baguette</li>
    </ul>
  </li>
  <li>Pastries
    <ul>
      <li>Butter croissant</li>
    </ul>
  </li>
</ul>

Das innere <ul> lebt innerhalb des <li> seiner Kategorie, bevor dieses li schließt - die Verschachtelungsregel bei echter Arbeit. Tippe nicht “1.” und “2.” von Hand in Absätze: ein Screenreader kündigt eine echte Liste an (“Liste, vier Einträge”) und lässt Nutzer sie überspringen; getippte Zahlen geben nichts davon.

Links

Das H in HTML steht für HyperText - Links sind das, was ein Web zu einem Web macht.

Eine URL lesen

Eine URL (Uniform Resource Locator) ist die Adresse einer Ressource. Jede zerfällt in drei Teile:

https

example.github.io

/my-site/

https - das Schema: welches Protokoll zu verwenden ist (hier das sichere Web-Protokoll).
example.github.io - die Domain: welchen Server man fragt.
/my-site/ - der Pfad: welche Ressource auf diesem Server.

Das `<a>`-Element

<a href="menu.html">See our menu</a>

Der Text zwischen den Tags ist das, was der Besucher anklickt - schreibe Text, der sagt, wohin er führt (“See our menu”, nicht “click here”). Screenreader-Nutzer springen oft von Link zu Link und hören nur die Link-Texte, und eine Seite voller “click here, click here” sagt ihnen nichts.

Zwei Arten von Adresse in href:

Relativ - zeigt von der aktuellen Datei zu einer anderen Datei in meinem eigenen Projekt: menu.html, images/hero.png. Kein Schema, keine Domain. Relative Links funktionieren überall weiter, wohin das Projekt geht (lokale Vorschau, Live-Server, die Kopie eines Teamkollegen).
Absolut - eine vollständige URL mit Schema und Domain: https://www.example.com. Verwende sie nur für Ziele außerhalb meines Projekts. Die eigene Live-URL fest in interne Links zu schreiben, ist die klassische selbstverschuldete Wunde: die Seite bricht dann überall außer unter dieser einen Adresse.

target="_blank" öffnet einen Link in einem neuen Tab. Innerhalb meiner eigenen Seite: niemals - Besucher navigieren in einem Tab, und der Zurück-Button gehört ihnen. Vertretbar nur für externe Links, und paare es mit rel="noopener" (kappt einen Zugriff, den die neue Seite sonst zurück auf deine bekäme):

<a href="https://www.example.com" target="_blank" rel="noopener">External site</a>

Bilder

<img src="images/hero.png" alt="The bakery counter with fresh loaves on wooden shelves.">

<img> ist ein void element - kein schließendes Tag, weil sein “Inhalt” die Bilddatei ist, auf die sein src zeigt. Alles wird in Attributen gesagt.

src - der Pfad zur Datei. Konvention: Bilder in einem images/-Ordner im Projekt halten und sie über einen relativen Pfad erreichen. Die Bilddatei wird mit dem Markup, das sie verwendet, committet, reviewt und veröffentlicht - immer im selben Commit, denn das eine ohne das andere ist ein kaputter Zustand.
alt - der Text, den ein Besucher anstelle des Bildes bekommt: von Screenreadern vorgelesen, angezeigt, wenn die Datei nicht lädt, von Suchmaschinen gelesen. Jedes Bild bekommt einen alt-Satz - einen vollständigen Satz, den ein Mensch hören und der Seite trotzdem folgen kann, kein Stichwort und nicht der Dateiname.

Seitenstruktur und Container

Fünf semantische Elemente benennen die Bereiche, die fast jede Seite hat. Jedes ist ein Bedeutungs-Label - wie strong, aber für einen ganzen Bereich:

header (nav)

→

main (section…)

→

footer

<body>
  <header>
    <nav> ... </nav>
  </header>
  <main>
    <section> ... </section>
  </main>
  <footer> ... </footer>
</body>

<header> - Einleitungsbereich, meist Seitenname und Navigation.
<nav> - die Navigation selbst, eine Gruppe von Links.
<main> - der einzigartige Inhalt dieser Seite (einer pro Seite).
<section> - eine thematische Gruppe innerhalb des Inhalts, meist mit einer Überschrift.
<footer> - Abschlussbereich, Kleingedrucktes und nebensächliche Infos.

Diese ändern kaum, wie irgendetwas aussieht. Was sie ändern, ist, was die Seite bedeutet: Screenreader kündigen sie als Landmarken an und lassen Nutzer direkt zu main oder nav springen und Wiederholungen überspringen. Suchmaschinen und Lesemodi stützen sich ebenfalls darauf, und eine barrierefreie Struktur ist für viele öffentliche Seiten eine Rechtsfrage - es ist die billigste Compliance-Arbeit, die es gibt, zur Schreibzeit kostenlos.

Die zwei bedeutungsfreien Container, für den Fall, dass ich Dinge rein zum späteren Stylen gruppieren muss:

<div> - ein Block-Container, der nichts über seinen Inhalt sagt.
<span> - ein Inline-Container, der nichts sagt, für ein paar Wörter innerhalb von Text.

<p>Whole loaf: <span>5.80</span></p>

Block vs. Inline

Jedes Element wird standardmäßig auf eine von zwei Arten dargestellt. Ich habe das die ganze Zeit schon gesehen - hier ist sein Name:

	Block-Level	Inline
Zeile	Beginnt in einer neuen Zeile	Fließt innerhalb einer Zeile
Breite	Nimmt die volle verfügbare Breite	Nimmt nur den Platz, den sein Inhalt braucht
Beispiele	Überschriften, `p`, Listen, `div`, alle 5 Struktur-Elemente	`strong`, `em`, `a`, `span`
Verhalten	Stapeln sich vertikal, jedes in eigener Zeile	Leben innerhalb von Zeilen, brechen sie nie

Block-Elemente türmen sich wie gestapelte Balken; Inline-Elemente sitzen im Fluss des Textes. Das ist das Standard-Verhalten jedes Elements, sichtbar noch vor einer einzigen Zeile CSS - später kann CSS’ display-Eigenschaft es ändern, was die Tür zum Layout ist.

Eine Seite mit mehr als einer Unterseite

Eine kleine Website ist einfach mehrere vollständige HTML-Dokumente, die im Projekt-Root nebeneinander liegen, neben dem images/-Ordner:

index.html - die Startseite. Sie behält diesen speziellen Namen, weil ein Webserver, wenn nach einem Ordner statt einer Datei gefragt wird, mit der index.html dieses Ordners antwortet. Deshalb braucht eine Live-Adresse wie example.github.io/my-site/ keinen Dateinamen.
menu.html, order.html - weitere Seiten, beschreibend benannt. Nur die Standardseite bekommt den speziellen Namen.

Jede Datei ist ein vollständiges Dokument: volle Anatomie, ihr eigenes <title> (damit sich drei offene Tabs auseinanderhalten lassen), ihr eigenes einzelnes <h1>.

Eine Navigation, auf jeder Seite - für eine kleine Website heißt das dasselbe Markup, in jede Datei kopiert:

<nav>
  <a href="index.html">Home</a>
  <a href="menu.html">Menu</a>
  <a href="order.html">Order</a>
</nav>

Ja, Kopien - wenn sich die Navigation ändert, aktualisiere ich sie alle. Spüre diesen kleinen Schmerz: identisches Markup zu wiederholen ist ein echtes Problem mit echten Lösungen (JavaScript) später, aber für ein paar Seiten ist ehrliche Wiederholung die richtige Entscheidung. Jede Seite verlinkt auf alle Seiten, sich selbst eingeschlossen, damit die Navigation stabil bleibt.

Tabellen für Daten

Eine Tabelle enthält Zeilen und Spalten zusammengehöriger Daten - und nichts sonst. (Bevor CSS Layout konnte, missbrauchten Entwickler Tabellen, um ganze Seiten zu positionieren; diese Praxis ist tot. Tabellen enthalten Daten; Layout gehört zu CSS.)

Tag	Zweck
`<table>`	Das Datenraster
`<thead>` / `<tbody>`	Umschließt die Kopfzeile / die Datenzeilen
`<tr>`	Eine Tabellenzeile
`<th>`	Eine Kopfzelle (benennt ihre Spalte oder Zeile)
`<td>`	Eine Datenzelle

<table>
  <thead>
    <tr>
      <th>Day</th>
      <th>Hours</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Saturday</td>
      <td>7:00 to 14:00</td>
    </tr>
    <tr>
      <td>Sunday</td>
      <td>Closed</td>
    </tr>
  </tbody>
</table>

thead und tbody sind keine Dekoration: Screenreader nutzen sie, um jede Kopfzelle mit den Daten anzukündigen, zu denen sie gehört, und CSS nutzt sie, um Kopf- vs. Datenzeilen getrennt anzusprechen (zum Beispiel jede zweite Datenzeile einzufärben). Datentabellen sind das korrekte, barrierefreie Element für Daten - nichts sonst erfüllt ihre Aufgabe.

Web-Formulare

Ein Web-Formular ist ein Seitenabschnitt, der Eingaben vom Besucher sammelt und irgendwohin sendet, zur Verarbeitung. Zwei Hälften: das Sammeln (HTMLs Aufgabe, und der ganze Inhalt dieses Abschnitts) und das Senden (hier konzeptionell erklärt, in späteren Kursen real gemacht).

Formulare sind überall, sobald man darauf achtet: das Suchfeld auf jeder Seite, Logins, Kassenvorgänge, Newsletter-Anmeldungen, Titel und Beschreibung eines Pull Requests. Formulare sind, wie das Web zuhört - der eine Mechanismus, durch den Seiten aufhören, nur lesbar zu sein.

Ein Formular bauen

Die Teile, von außen nach innen:

Tag	Zweck
`<form>`	Container für einen Satz Fragen + sein Absende-Steuerelement
`<fieldset>`	Eine Gruppe zusammengehöriger Fragen
`<legend>`	Der sichtbare Titel eines fieldset
`<label>`	Der sichtbare Name eines Inputs, per `for` mit ihm verbunden
`<input>`	Eine Frage; ihr `type` entscheidet, welche Art (void element)
`<textarea>`	Mehrzeiliger Freitext
`<select>` + `<option>`	Aus einer festen Liste wählen
`<button type="submit">`	Sendet das Formular

Vier Attribute, die bei Inputs zählen:

type - welche Art von Frage. Häufig: text (Freitext), email (Browser prüft auf E-Mail-Form), radio (genau eines aus einer Gruppe wählen), checkbox (beliebig viele wählen). Radio für eines, checkbox für viele. Radios, die sich ein name teilen, bilden eine Wähle-eins-Gruppe; einem das Attribut checked zu geben, wählt eine Vorgabe vor.
name - der Schlüssel, unter dem der Wert reist (customer-name=Sarah). Ein Input ohne name sendet nichts, stillschweigend - das Feld sieht perfekt aus und seine Daten verlassen es nie. Das ist das wichtigste Attribut, das man nie vergessen darf.
required - der Browser weigert sich abzusenden, solange das Feld leer ist, mit seiner eigenen eingebauten Meldung, kein Code nötig.
placeholder - schwacher Beispieltext in einem leeren Feld. Ein Beispiel, niemals ein Label - er verschwindet in dem Moment, in dem das Tippen beginnt.

Hier ist ein vollständiges, kopierbares Formular, das jede Regel auf einmal zeigt:

<form action="#" method="get">

  <fieldset>
    <legend>Who is picking up</legend>

    <label for="customer-name">Your name</label>
    <input type="text" id="customer-name" name="customer-name"
           required placeholder="e.g. Alex Example">

    <label for="customer-email">Email</label>
    <input type="email" id="customer-email" name="customer-email" required>
  </fieldset>

  <fieldset>
    <legend>Pickup day</legend>

    <input type="radio" id="day-sat" name="pickup-day" value="saturday" checked>
    <label for="day-sat">Saturday</label>

    <input type="radio" id="day-sun" name="pickup-day" value="sunday">
    <label for="day-sun">Sunday</label>

    <label for="pickup-time">Pickup time</label>
    <select id="pickup-time" name="pickup-time">
      <option value="morning">Morning</option>
      <option value="afternoon">Afternoon</option>
    </select>
  </fieldset>

  <fieldset>
    <legend>Your order</legend>

    <input type="checkbox" id="item-loaf" name="items" value="loaf">
    <label for="item-loaf">Sourdough loaf</label>

    <input type="checkbox" id="item-croissant" name="items" value="croissant">
    <label for="item-croissant">Croissant</label>

    <label for="notes">Notes for the bakers</label>
    <textarea id="notes" name="notes"></textarea>
  </fieldset>

  <button type="submit">Place pre-order</button>

</form>

Lies die Radio-Gruppe genau: beide teilen sich name="pickup-day", also schließen sie einander aus, jede hat eine eigene id, jede ihr eigenes verbundenes Label, und Saturday ist mit checked vorgewählt.

Was beim Absenden passiert

Zwei Attribute am <form> beschreiben das Senden:

action - die Adresse, an die die Daten gesendet werden.
method - wie sie reisen: get oder post.

Mit action="#" (dieselbe Seite) und method="get" und ganz ohne Server kann ich ein Absenden beobachten: das Formular ausfüllen, absenden drücken und die Adresszeile lesen. Die URL trägt nun jedes benannte Feld als Schlüssel-Wert-Paare nach einem ?:

mypage.html?customer-name=Alex&pickup-day=saturday&items=loaf

Die Schlüssel kommen aus den name-Attributen, die Werte aus dem, was der Besucher getippt hat. Das ist auch der Beweis, dass unbenannte Felder verschwinden - alles ohne ein name ist schlicht nicht in dieser URL.

	GET	POST
Wohin die Daten gehen	In die URL, sichtbar & als Lesezeichen speicherbar	Innerhalb der Anfrage, außerhalb der URL
Richtig für	Suchen, Filter - die Daten sind eine Frage	Bestellungen, Logins, Nachrichten - Änderungen oder private Daten

Wiederholungs-Zusammenfassung

Kernpunkt	Kurz gemerkt
Drei Sprachen	HTML = Struktur, CSS = Aussehen, JS = Verhalten - je eine Aufgabe
Was HTML ist	HyperText Markup Language - Labels, die sagen, was Inhalt ist, nie wie er aussieht
Dokument-Anatomie	doctype → `html` → `head` (über die Seite) → `body` (was sichtbar ist)
Die zwei meta-Zeilen	`charset="UTF-8"` (Alphabet) + viewport (echte Breite auf Smartphones) - fest in jedem head
Element vs. Tag vs. Attribut	Element = Markup + Inhalt; Tag = der Marker in spitzen Klammern; Attribut = `name="value"` im öffnenden Tag
Void elements	`<meta>`, `<img>`, `<br>`, `<input>` - kein Inhalt, kein schließendes Tag
Verschachtelungsregel	Zuletzt geöffnet, zuerst geschlossen - Kisten in Kisten, niemals überlappend
Überschriften	`h1`-`h6` sind eine gereihte Gliederung, keine Größen; ein `h1`, keine Ebenen überspringen
Leerraum fällt zusammen	Folgen von Leerzeichen/Umbrüchen werden zu einem Leerzeichen - nur Elemente erzeugen Struktur
strong vs. em	`strong` = wichtig (überlebt außerhalb des Kontexts); `em` = stimmliche Betonung
Listen	`ul` (reihenfolgefrei), `ol` (Reihenfolge zählt), `li`-Punkte; nur `li` direkt darin
Links	`<a href>`; relativ innerhalb des Projekts, absolut nur für Externes
Bilder	`<img src alt>` void; jedes Bild bekommt einen alt-Satz; kleingeschriebene Namen; komprimieren
Semantische Struktur	`header nav main section article footer` = Landmarken; `div`/`span` nur, wenn keine Bedeutung passt
Block vs. Inline	Block = eigene Zeile, volle Breite; Inline = fließt im Text, Inhaltsbreite
index.html	Server liefert standardmäßig die `index.html` eines Ordners - das ist die Startseite
Tabellen	`table/thead/tbody/tr/th/td` nur für Daten, nie fürs Layout
Formular-Grundlagen	`form` rahmt es; jedes `input` braucht ein verbundenes `label` und ein `name` (kein name → sendet nichts)
Input-Typen	`text`, `email`, `radio` (eines, geteiltes name), `checkbox` (viele), plus `textarea`/`select`
Beim Absenden	`action` = wohin, `method` = wie; GET = Daten in URL, POST = Daten verborgen; echte Validierung ist serverseitig