Kerncurriculum kompakt
E2 als Lernweg vom strukturierten Artikel zum gemeinsamen Informatik-Wiki

Das Themenfeld E.2 HTML-Dokumente bündelt vier fachliche Linien, die im Kurs-Wiki nicht nebeneinander stehen, sondern aufeinander aufbauen:

Hypertext Markup Language (HTML5): HTML-Grundgerüst, grundlegende HTML-Elemente, öffnende und schließende Tags, HTML-Attribute, Attributwerte und Hyperlinks.
Struktur von HTML-Dokumenten: Dokumentbaum, Schachtelung, semantische Bereiche, Tabellen, Listen, Bilder und Bildbeschreibungen.
Cascading Style Sheets (CSS3): Selektoren, grundlegende CSS-Eigenschaften, CSS-Klassen, wiederverwendbare Gestaltung und externe Stylesheets.
Formulare: Eingabefelder, Formularstruktur und Versand der Eingabedaten als kleiner Ausblick auf spätere Webanwendungen.

Die Lesebewegung lautet: Inhalt strukturieren, den Dokumentbaum verstehen, Artikel verlinken, Darstellung vereinheitlichen und Qualität prüfen. Damit bleibt E2 im Zentrum bei HTML-Struktur, Hypertext und CSS. Formulare markieren nur den späteren Übergang: Formular → HTTP-Anfrage → serverseitige Verarbeitung → Datenbank.

Die Detailarbeit konkretisiert diese Linien am HTML-Grundgerüst mit <!DOCTYPE html>, <html>, <head>, Meta-Angaben, <title> und <body> sowie an relativen, absoluten und dokumentinternen Verweisen. Entscheidend ist dabei nicht das Kopieren einer fertigen Wiki-Vorlage, sondern die Frage, welche HTML- und CSS-Mittel ein konkreter Artikel wirklich braucht.

Als roter Faden dient ein gemeinsames Informatik-Wiki. Es besteht aus mehreren Artikeln, etwa in Ordnern wie hardware/, geschichte/, begriffe/ und bilder/. An diesem Kontext wird sichtbar, warum strukturierte Artikel, einheitliche Dateipfade, interne Links, gemeinsame Gestaltungsregeln, Quellenangaben und barrierearme Bildbeschreibungen notwendig werden.

Curricularer Orientierungsrahmen E2

E2 führt von einzelnen Webdokumenten zu einem gemeinsamen Hypertext: strukturierter Artikel, Informationsbausteine, Dokumentbaum, interne Verlinkung, gemeinsame CSS-Regeln und Qualitätsprüfung. Die Brücke zu Q2.3 bleibt erhalten, aber sie ist Anschluss, nicht Zentrum: Formular → HTTP-Übertragung → PHP-Verarbeitung → Datenbank → dynamische Ausgabe.

HTML als Struktur- und Auszeichnungssprache
Warum Tags Bedeutung markieren und nicht einfach Designbefehle sind

HTML ist eine Auszeichnungssprache. Sie beschreibt, welche Rolle ein Inhalt im Dokument besitzt: Titel, Einleitung, Absatz, Abschnitt, Liste, Tabelle, Bild, Link oder Quellenbereich. In einem Informatik-Wiki wird damit nicht nur Text formatiert, sondern Wissen modelliert: Ein Artikel über ein Thema erhält eine lesbare innere Ordnung.

Ein HTML-Tag ist kein Befehl im Sinne eines Programms. Es markiert, welche Rolle ein Inhalt im Dokument hat. Ein <h1>-Element bedeutet nicht einfach: „mache diesen Text groß“, sondern: „dies ist die Hauptüberschrift“. Ein <p>-Element bedeutet nicht: „setze Abstand“, sondern: „dies ist ein Absatz“. Die sichtbare Darstellung übernimmt später CSS.

Merksatz

HTML zeichnet Bedeutung und Struktur aus; CSS beschreibt die Darstellung dieser Struktur.

Warum diese Trennung didaktisch so wichtig ist

Diese Trennung ist mehr als eine Stilregel. Sie macht ein gemeinsames Wiki überhaupt wartbar: Wenn jede Gruppe Überschriften, Absätze oder Hervorhebungen nur nach Aussehen setzt, passen die Artikel später nicht zusammen. Wenn HTML zuerst die Bedeutung beschreibt und CSS die Darstellung übernimmt, können viele Artikel einheitlich gelesen, geprüft und weiterentwickelt werden.

Code

<h1>Artikelthema</h1>
<p>Kurze Einleitung mit dem wichtigsten Gedanken.</p>

Browseransicht / Ergebnis

Artikelthema

Kurze Einleitung mit dem wichtigsten Gedanken.

Links steht die Auszeichnung, rechts die Browseransicht. HTML legt hier nicht Farbe und Abstand als Designentscheidung fest, sondern markiert: Dies ist die Hauptüberschrift, dies ist ein Absatz.

Im Wiki-Kontext löst dieses Beispiel noch keinen vollständigen Artikel. Es zeigt nur ein Prinzip: Ein Inhalt erhält eine Rolle. Ob später weitere Abschnitte, Tabellen, Listen, Bilder oder Links nötig sind, ist eine fachliche Modellierungsentscheidung des jeweiligen Artikels.

Modellierungsfragen nach dem Codebeispiel

Welche Information deines Themas ist wirklich der Artikeltitel?
Welche Information gehört in die Einleitung, weil sie Orientierung gibt?
Welche Informationen brauchen eigene Abschnitte statt einen langen Fließtext?
Welche Gestaltung gehört später in CSS, nicht in das HTML-Markup?

Vom Quelltext zum Dokumentbaum: Browserinterpretation und DOM
Warum HTML als Strukturmodell verstanden werden muss

Jede HTML-Seite besitzt ein Grundgerüst mit <!DOCTYPE html>, <html>, <head> und <body>. Entscheidend ist dabei nicht nur die Reihenfolge, sondern die Verschachtelung: Elemente liegen in anderen Elementen und bilden so eine Hierarchie.

<!DOCTYPE html>
<html lang="de">
  <head>
    <meta charset="UTF-8">
    <title>Wiki-Artikel</title>
    <link rel="stylesheet" href="../css/wiki.css">
  </head>
  <body>
    <main>...Artikelinhalt...</main>
  </body>
</html>

Beim Arbeiten mit HTML gibt es drei Perspektiven auf dieselbe Webseite. Der Quelltext ist das, was geschrieben wird. Der Dokumentbaum ist die Struktur, die der Browser daraus intern aufbaut. Die gerenderte Seite ist das, was Nutzende im Browser sehen. Wer HTML versteht, kann zwischen diesen Perspektiven wechseln: Ein Fehler im Quelltext verändert den Dokumentbaum und kann dadurch die sichtbare Darstellung beeinflussen.

Quelltext

<article>
  <header>
    <h1>Artikelthema</h1>
  </header>
  <section>
    <h2>Teilfrage</h2>
    <p>Kurze Erklärung.</p>
  </section>
</article>

Dokumentbaum

html
└── body
    └── main
        └── article
            ├── header
            │   └── h1
            └── section
                ├── h2
                └── p

Gerenderte Seite

Artikelthema

Teilfrage

Kurze Erklärung.

Der Quelltext ist linear geschrieben. Der Browser baut daraus eine Baumstruktur. Die gerenderte Seite ist die sichtbare Ausgabe dieser Struktur. Tabellen, Bilder oder Navigationsbereiche könnten später weitere Knoten werden; sie werden hier noch nicht als fertige Artikelvorlage ausformuliert.

Öffnende und schließende Tags korrekt lesen

Viele HTML-Elemente bestehen aus einem öffnenden Tag, einem Inhalt und einem schließenden Tag. Das schließende Tag erkennt man am Schrägstrich. Es beendet genau den Bereich, der zuvor geöffnet wurde. Wird diese Reihenfolge verletzt, entsteht ein anderer oder fehlerhafter Dokumentbaum.

<article>
  <h2>Abschnittstitel</h2>
  <p>Dieser Absatz gehört zum Abschnitt.</p>
</article>

<article> öffnet den Inhaltsbereich, </article> schließt ihn. Die Überschrift und der Absatz liegen innerhalb dieses Bereichs. Dadurch entsteht im Dokumentbaum eine klare Eltern-Kind-Struktur.

Falsch geschachtelt

<p>Ein Thema <strong>wird erklärt.</p></strong>

Richtig geschachtelt

<p>Ein Thema <strong>wird erklärt.</strong></p>

Beim Schließen gilt: Das zuletzt geöffnete Element wird zuerst geschlossen. Einige Elemente sind dagegen leer beziehungsweise selbstständig, etwa <img> oder <meta>. Sie besitzen keinen eingeschlossenen Textinhalt, sondern werden über HTML-Attribute wie src, alt oder charset und den jeweiligen Attributwert beschrieben.

Baumstruktur (DOM-Grundidee) verstehen

Der Browser behandelt HTML nicht als flachen Text. Durch Schachtelung entstehen Eltern-, Kind- und Geschwisterbeziehungen. Genau diese Beziehungen bilden den Dokumentbaum. CSS kann später gezielt Elemente in dieser Struktur auswählen. JavaScript kann den Dokumentbaum im Browser verändern, ist in E2 aber nicht das Lernzentrum. Zuerst muss die HTML-Struktur stimmen.

Elternknoten: z. B. main oder section
Kindknoten: z. B. h2 und p innerhalb einer Section
Geschwisterknoten: Elemente auf derselben Hierarchiestufe im Dokumentbaum
Fehlerdiagnose: fehlende schließende Tags, falsche Schachtelung oder ungültige Ressourcenpfade können zu unerwarteter Darstellung führen.

Modellierungsfragen zum Dokumentbaum

Welche Bereiche liegen innerhalb des Artikels?
Welche Abschnitte sind gleichgeordnet?
Welche Elemente sind Eltern-, Kind- oder Geschwisterelemente?
Welche Folgen hätte falsche Schachtelung für CSS, Lesbarkeit oder Barrierearmut?

Semantische HTML-Elemente und Inhaltsstruktur
Artikelgrammatik statt Elementliste: Rollen, Bausteine und Informationsentscheidungen

Die folgenden Elemente sind keine Vokabelliste. Sie bilden eine Art Artikelgrammatik für das Informatik-Wiki. Ein Wiki-Artikel muss klären: Was ist der Artikeltitel? Was ist die Einleitung? Welche Unterthemen brauchen Abschnitte? Welche Fakten gehören in eine Tabelle? Welche Begriffe werden als Liste verständlicher? Welche Bilder brauchen eine Aussage, eine Beschriftung und eine Quelle?

Semantische HTML-Elemente beschreiben nicht zuerst, wie etwas aussieht, sondern welche Rolle ein Inhalt im Dokument übernimmt. Eine Navigation ist nicht nur eine Gruppe von Links, sondern ein Navigationsbereich; ein Abschnitt ist nicht nur ein Kasten, sondern eine inhaltlich zusammengehörige Einheit. Browser, Suchmaschinen, Screenreader, CSS-Regeln und spätere Skripte profitieren davon, wenn diese Rollen sauber im Dokumentbaum erkennbar sind.

Damit ist Semantik keine Gestaltung, sondern Struktur- und Bedeutungsmodellierung. CSS-Klassen können Bereiche wiedererkennbar gestalten oder technisch adressierbar machen, ersetzen aber nicht die fachliche Bedeutung eines Elements. Ein <div class="navigation"> kann aussehen wie eine Navigation; <nav> sagt zusätzlich, dass dieser Bereich als Navigation gemeint ist.

<h1> / <h2> Artikeltitel und Unterthemen

<p> Einleitung oder erklärender Absatz

<article> / <section> Artikel und inhaltliche Abschnitte

<table> Vergleichbare Fakten in Zeilen und Spalten

<ol> / <ul> Sammlung, Reihenfolge oder Unterpunkte

<figure> / <img> / <figcaption> Abbildung, Bildaussage und Beschriftung

Diese Elemente beantworten Strukturfragen eines Artikels. Sie legen noch nicht fest, wie ein bestimmter Artikel später aussehen muss.

1) Strukturierende Elemente

Überschriften <h1> bis <h6> strukturieren Themenebenen, <p> markiert inhaltliche Absätze. Elemente wie <main>, <article>, <section> oder <nav> machen größere Rollen im gemeinsamen Wiki sichtbar. <nav> kann später einen Navigationsbereich markieren, wird hier aber nicht als fertige Kursnavigation vorgegeben.

<header>
  <h1>Artikelthema</h1>
  <p>Kurze Orientierung zum Thema.</p>
</header>
<main>
  <article>
    <section>
      <h2>Teilfrage</h2>
      <p>Erklärung in eigenen Worten.</p>
    </section>
  </article>
</main>

Das Beispiel zeigt Rollen: Orientierung, Artikel, Abschnitt und Absatz. Es ist keine fertige Wiki-Vorlage und enthält bewusst keine vollständige Navigation, Infobox oder Quellenstruktur.

2) Tabellen und Listen als Informationsentscheidungen

Tabellen sind keine Layoutmittel. Sie eignen sich, wenn Informationen vergleichbar sind und in Zeilen und Spalten sauber gelesen werden sollen. Listen eignen sich für Sammlungen, Reihenfolgen oder Unterpunkte. Die Entscheidung hängt vom Inhalt ab, nicht vom gewünschten Aussehen.

Tabellenprinzip

<table>
  <tr><th>Merkmal</th><th>Wert</th></tr>
  <tr><td>Begriff</td><td>Kurzangabe</td></tr>
</table>

Listenprinzip

<ul>
  <li>erster Aspekt</li>
  <li>zweiter Aspekt</li>
</ul>

Beide Beispiele bleiben neutral. Sie zeigen nur die Sprachmittel für vergleichbare Fakten und Aufzählungen, nicht die fertigen Inhalte eines Hardware- oder Geschichtsartikels.

3) Verweise und Medien im Gesamtsystem

<a> verbindet Dokumente im Hypertext-System. <img> bindet externe Ressourcen ein; über alt wird die Bildaussage textlich beschrieben. <figure> und <figcaption> können Bild und Beschriftung semantisch zusammenhalten.

<section>
  <h2>Begriffe und Verweise</h2>
  <ol>
    <li>zentralen Begriff erklären</li>
    <li>passenden Wiki-Artikel verlinken</li>
    <li>Quelle oder Abbildung prüfen</li>
  </ol>
</section>

Semantik vor Container

Zuerst wird geprüft, ob ein passendes semantisches Element existiert: Überschrift, Absatz, Liste, Navigation, Abschnitt, Bild, Formularbereich oder Fußbereich. Erst wenn keine passende Bedeutung vorliegt oder eine technische Gruppierung nötig ist, wird ein neutraler Container sinnvoll.

Ein <div> trägt selbst keine fachliche Bedeutung. Es gruppiert Inhalte, damit sie gemeinsam gestaltet, positioniert oder später durch Skripte angesprochen werden können. Damit gehört der Containerbegriff bereits an die Schnittstelle zu CSS.

Modellierungsfragen zu Elementen, Tabellen und Listen

Welche Informationen sind vergleichbar und gehören in Spalten?
Welche Informationen sind eher Aufzählung als Tabelle?
Welche Reihenfolge ist fachlich begründet?
Wo wäre eine geschachtelte Liste sinnvoll?
Welche Bilder brauchen eine Bildaussage und eine Quelle?

Der Wiki-Artikel als Strukturmodell
Warum ein Artikel nicht bloß Text, sondern modellierte Information ist

Ein Wiki-Artikel ist nicht einfach ein längerer Text auf einer Webseite. Er ist eine modellierte Informationsstruktur. Ein Thema wird so geordnet, dass andere es lesen, vergleichen, verlinken, prüfen und später erweitern können. Dafür können Bausteine wie Titel, Kurzbeschreibung, Überblick, Faktenbereich, Erklärung, Abbildung, verwandte Artikel und Quellen wichtig werden.

Diese Bausteine sind aber keine Pflichtschablone. Ein Artikel über ein Gerät, ein historisches Ereignis oder einen Fachbegriff braucht nicht automatisch dieselbe Struktur. Entscheidend ist, welche Informationen wiederkehren, welche themenspezifisch sind und welche Konventionen das ganze Kurs-Wiki gemeinsam braucht.

<article>
  <h1>[Titel des Artikels]</h1>
  <p>[kurze Orientierung]</p>

  <section>
    <h2>[passender Abschnitt]</h2>
    <p>[eigene Erklärung]</p>
  </section>
</article>

Das Beispiel zeigt Platzhalter und Strukturprinzipien. Es ist keine fertige Musterseite für ein bestimmtes Informatikthema und legt keine endgültige Wiki-Architektur fest.

Titel Worum geht es genau?

Kurzbeschreibung Welche Orientierung brauchen Lesende zuerst?

Faktenbereich Welche Angaben sind knapp vergleichbar?

Erklärung Welche Zusammenhänge müssen verstanden werden?

Abbildung Welche Bildaussage ergänzt den Text?

Quellen Welche Herkunft muss nachvollziehbar bleiben?

Modellierungsfragen zum Wiki-Artikel

Welche Bausteine braucht dein Thema wirklich?
Welche Informationen wiederholen sich bei vielen Artikeln?
Welche Informationen sind nur für dieses Thema wichtig?
Welche Struktur sollte im ganzen Kurs-Wiki gleich bleiben?
Welche Entscheidung darf nicht durch ein fertiges Codebeispiel vorweggenommen werden?

Hypertext und Verlinkung als Kernidee des Webs
Warum Links Beziehungen zwischen Dokumenten, Begriffen und Lernwegen modellieren

Ein Link ist mehr als ein Sprungziel. Er modelliert eine Beziehung zwischen Dokumenten. Durch Hyperlinks entsteht aus einzelnen Dateien ein Hypertext: Nutzende können Hyperlinks folgen, Begriffe vertiefen, zu Quellen wechseln oder zwischen Teilbereichen des Wikis navigieren.

<a href="../begriffe/beispiel.html">verwandter Begriff</a>

Der href-Wert bestimmt das Ziel. Erst solche Verknüpfungen machen aus einer einzelnen Artikelseite ein Wiki. Ein Hypertext entsteht nicht durch eine Datei allein, sondern durch Beziehungen zwischen Artikeln, Ankern, Quellen und Ressourcen.

Startseite index.html ordnet die Artikelbereiche

hardware/beispiel.html

geschichte/beispiel.html#abschnitt

begriffe/beispiel.html

index.html steht hier nur als möglicher Einstieg. Die Dateinamen sind Platzhalter für Bereiche des Kurs-Wikis, keine fertige Navigationslösung.

<!-- relativer Link im Wiki -->
<a href="../hardware/beispiel.html">verwandter Artikel</a>

<!-- Ankerlink zu einer Stelle im Artikel -->
<a href="#quellen">zu den Quellen</a>

<!-- externe Quelle, nicht Navigation -->
<a href="https://example.org/quelle" rel="noopener">Quelle anzeigen</a>

Relative Verlinkungen beschreiben Ziele ausgehend vom aktuellen Dateistandort und sind deshalb besonders wichtig innerhalb eines Wikis. Absolute Verlinkungen enthalten ein vollständiges Ziel, etwa eine externe Webadresse. Ankerlinks führen zu einer bestimmten Stelle innerhalb eines Dokuments. Ressourcenpfade verweisen auf Dateien wie Bilder oder Stylesheets. Für ein gemeinsames Wiki ist diese Unterscheidung entscheidend, weil sonst interne Verweise, Quellen und Medien durcheinander geraten.

Relative Verlinkung
../hardware/beispiel.html

Ankerlink
#quellen

Externe Quelle
https://example.org/quelle

Ressourcenpfad
../bilder/beispiel.svg

D-Book als reales Hypertext-System

Das D-Book macht diese Idee selbst sichtbar. Inhaltsseiten, Glossaranker, Suche, Werkzeuge und Wissensnetz sind nicht zufällig verlinkt. Sie bilden kuratierte Zugänge zu denselben fachlichen Begriffen. Ein Glossarlink führt nicht nur zu einer anderen Seite, sondern öffnet einen Begriffskontext; ein Wissensnetz-Embed zeigt Beziehungen zwischen Begriffen; eine Werkzeugseite macht einen Begriff operativ erfahrbar.

Modellierungsfragen zu Links

Welche Artikel sollten direkt miteinander verlinkt werden?
Welche Begriffe brauchen interne Verweise?
Welche externen Links sind Quellen und keine Navigation?
Welche Startseite braucht ein gemeinsames Wiki, ohne jede Entscheidung vorwegzunehmen?
Welche Ressourcenpfade müssen relativ zur aktuellen Datei stimmen?

Cascading Style Sheets (CSS) als Darstellungsschicht: Selektoren, CSS-Klassen, Layout
Wie viele Artikel eine gemeinsame, aber nicht vorgefertigte Gestaltung erhalten

Cascading Style Sheets bedeutet sinngemäß: gestufte Gestaltungsregeln. Mehrere Regeln können auf dasselbe Element wirken; welche Regel sichtbar wird, hängt unter anderem von Reihenfolge, Spezifität und Vererbung ab. Style Sheets sind Regelblätter: Gestaltung wird getrennt von der HTML-Struktur beschrieben.

CSS ist damit die Darstellungsschicht über der HTML-Struktur. Eine CSS-Regel besteht aus einem Selektor und Deklarationen: Der Selektor bestimmt, welche Elemente gemeint sind; die Deklarationen legen Eigenschaften wie Farbe, Abstand, Schrift oder Layout fest. Dadurch wird nicht die Bedeutung des Inhalts verändert, sondern seine sichtbare Darstellung.

Im Kurs-Wiki entsteht CSS aus einem praktischen Problem: Einzelne Artikel funktionieren zunächst für sich, sehen beim Zusammenführen aber uneinheitlich aus. Überschriften, Tabellen, Bildgrößen, Hervorhebungen und Abstände müssen deshalb gemeinsam geregelt werden, ohne dass jeder Artikel seine eigene Gestaltung in das HTML schreibt.

.hinweis {
  border: 1px solid #4d89c7;
  padding: 0.75rem;
  background: #102033;
}

Selektor: .hinweis wählt alle Elemente mit dieser CSS-Klasse aus.
Deklaration: padding: 0.75rem; legt eine konkrete Darstellungseigenschaft fest.
Wiederverwendung: dieselbe Regel kann auf mehreren Seiten und Elementen wirken.

CSS-Klassen als Schnittstelle zwischen HTML und CSS

CSS-Klassen verbinden die HTML-Struktur mit der Darstellungsschicht. Im HTML markiert class="hinweis", dass ein Bereich zu einem wiederverwendbaren Gestaltungsmuster gehört. Im CSS wählt der Selektor .hinweis genau diese Bereiche aus und legt fest, wie sie dargestellt werden. Dadurch bleibt die Bedeutung im HTML lesbar, während die Gestaltung zentral und wiederverwendbar im Stylesheet geregelt wird.

Neutrale Container wie <div> können solche Muster technisch gruppieren, sind aber keine semantischen Elemente. Wenn ein passendes Element wie <nav>, <main>, <section> oder <article> existiert, bleibt es die bessere Strukturentscheidung. Semantische Elemente können ebenfalls eine CSS-Klasse tragen; die CSS-Klasse ersetzt ihre Bedeutung nicht.

Semantisch

<section class="hinweis">
  <h2>Hinweis</h2>
  <p>Kurze Ergänzung zum Artikel.</p>
</section>

Nur technisch gruppiert

<div class="hinweis">
  <h2>Hinweis</h2>
  <p>Kurze Ergänzung zum Artikel.</p>
</div>

Beide Varianten können über CSS gleich aussehen. <section> sagt zusätzlich: Dieser Bereich ist ein inhaltlicher Abschnitt. <div> gruppiert nur technisch und ist deshalb nachgeordnet, wenn es ein semantisch passendes Element gibt.

Wiederverwendbare Struktur und zentrale Gestaltungsregel

HTML-Struktur

<section class="hinweis">
  <h2>Ergänzung</h2>
  <p>Dieser Hinweis kann in mehreren Artikeln vorkommen.</p>
</section>

CSS-Regel

.hinweis {
  border: 1px solid #4d89c7;
  padding: 0.75rem;
  background: #102033;
}

Die CSS-Klasse wird über das class-Attribut im HTML eingetragen, die Gestaltungsregel steht im CSS. So kann dieselbe Struktur auf mehreren Seiten gleich dargestellt werden, ohne die Darstellung in jedes HTML-Element zu schreiben.

In einem Artikel kann dieselbe Beispielklasse eine kurze Ergänzung markieren, in einem anderen einen Quellenhinweis oder eine Lesestütze. Daraus folgt noch kein endgültiges Klassensystem. Der Kurs muss später entscheiden, welche Klassen wirklich wiederverwendbar sind und welche Unterschiede fachlich sinnvoll bleiben.

Ergänzung Die Klasse markiert eine wiederverwendbare Darstellungsrolle.

Quelle Die Darstellung bleibt gleich, obwohl der Inhalt wechselt.

Lesestütze Die Klasse ist Beispiel, keine verpflichtende Wiki-Architektur.

Der Inhalt ändert sich, die Gestaltungslogik bleibt gleich. Genau dafür sind CSS-Klassen in größeren Webprojekten wichtig.

Sobald ein Artikel aus mehreren Bereichen besteht, etwa einem Haupttext und einem Faktenbereich, reicht reine Textformatierung nicht mehr aus. Layoutverfahren wie CSS Grid ordnen solche Bereiche systematisch in Zeilen und Spalten. Dadurch wird Gestaltung planbar und kann sich an unterschiedliche Bildschirmgrößen anpassen.

Codeausschnitt

.artikel-layout {
  display: grid;
  grid-template-columns: 2fr 1fr;
  gap: 1rem;
}

Gerendertes Mini-Layout

Erklärung

Hier steht der Hauptbereich eines Artikels.

Grid ordnet Bereiche, nicht einzelne Textfragmente. Es löst ein Layoutproblem: Wie werden Inhaltsbereich und Faktenbereich systematisch angeordnet?

External CSS als gemeinsame Projektschnittstelle

Solange jede Gruppe nur an einer Einzelseite arbeitet, wirken lokale Formatierungsentscheidungen unproblematisch. Beim Zusammenführen zum Kurs-Wiki entstehen Konflikte: unterschiedliche Farben, unterschiedliche Überschriftenhierarchien, uneinheitliche Tabellen, verschiedene Bildgrößen, doppelte CSS-Regeln, widersprüchliche Klassennamen und uneinheitliche Navigation.

Ein externes Stylesheet löst dieses Problem nicht automatisch, macht es aber bearbeitbar. Es wird zur gemeinsamen Projektschnittstelle: Regeln, die für alle Artikel gelten sollen, stehen nicht in jeder HTML-Datei, sondern in einer gemeinsamen CSS-Datei.

HTML bindet das Stylesheet ein

<link rel="stylesheet" href="../css/wiki.css">

Eine gemeinsame Regel

figure {
  max-width: 36rem;
}

Auch dieses Beispiel gibt kein vollständiges Stylesheet vor. Es zeigt nur, dass gemeinsame Regeln an einer gemeinsamen Stelle liegen können.

Modellierungsfragen zu CSS und external CSS

Welche Gestaltung soll für alle Artikel gleich sein?
Welche Unterschiede sind fachlich sinnvoll?
Welche Regeln gehören in ein gemeinsames Stylesheet?
Welche Klasse beschreibt eine wiederverwendbare Darstellungsrolle?
Wo wäre semantische HTML-Struktur besser als eine zusätzliche Klasse?
Welche Klassennamen sind verständlich und wiederverwendbar?

Bilder, Medien und Ressourcen fachlich einordnen
Warum Medien Teil von Struktur, Ressourcenpfaden und Qualitätsentscheidungen sind

Bilder und Medien sind in einer Webseite nicht nur Schmuck. Sie können Informationen erklären, Abläufe veranschaulichen, Quellen sichtbar machen oder Inhalte zugänglich ergänzen. In einem Informatik-Wiki ist ein Bild deshalb ein erklärender Baustein: Es muss zum Artikel passen, eine klare Bildaussage besitzen und mit Pfad, Beschreibung und Quelle nachvollziehbar eingebunden werden.

Informationsrolle: Diagramme, Fotos oder Skizzen ergänzen Textinhalte.
Strukturrolle: Das Bild ist ein Element im Dokumentbaum und kann mit Beschriftung verbunden werden.
Ressourcenbezug: src verweist auf eine Datei, deren Ressourcenpfad stimmen muss.
Qualitätsbeitrag: alt, Bildunterschrift und Quelle sichern Zugänglichkeit und Nachvollziehbarkeit.

Ressourcenpfade und Dateiorganisation systematisieren

Nach der fachlichen Rolle folgt die technische Einbindung: Ein Bild ist in HTML nicht einfach im Dokument enthalten. Es wird über einen Ressourcenpfad als externe Ressource referenziert. Ein falscher Ressourcenpfad führt nicht zu einem Syntaxfehler im Text, aber dazu, dass die Ressource im Browser nicht erscheint.

<img src="../bilder/beispiel.svg" alt="Kurze Beschreibung der Bildaussage">

src organisiert die Datei im Projekt, alt beschreibt die Bildaussage. Damit werden Ressourcenpfad und fachliche Bedeutung bewusst getrennt.

Code

<figure>
  <img src="../bilder/beispiel.svg" alt="[präzise Bildaussage]">
  <figcaption>[Bildunterschrift und Quelle]</figcaption>
</figure>

Platzhaltergrafik ohne neues Bildasset

Bilddatei Artikel Beschriftung

Bild, Aussage und Quelle gehören zusammen.

Der alt-Text beschreibt die inhaltliche Rolle eines Bildes. Er ist wichtig, wenn ein Bild nicht geladen wird oder wenn Screenreader die Seite vorlesen. <figure> und <figcaption> binden Bild und Beschreibung zusätzlich semantisch zusammen. Damit wird ein Bild nicht nur dekorativ eingefügt, sondern als erklärender Bestandteil des Dokuments ausgezeichnet.

src verweist auf eine Ressource, alt beschreibt die Bildaussage, <figcaption> bindet eine sichtbare Beschriftung an.

Zur Qualität eines Wiki-Artikels gehören außerdem knappe Verantwortungsperspektiven: Ist die Bilddatei sinnvoll benannt? Liegt sie im passenden Projektordner? Darf sie verwendet werden? Ist die Quelle genannt? Ist der alt-Text so formuliert, dass die Bildaussage auch ohne sichtbares Bild verständlich bleibt?

Modellierungsfragen zu Medien und Ressourcen

Welche Bildaussage ergänzt den Artikel wirklich?
Was muss im alt-Text stehen?
Welche Quelle muss genannt werden?
Wo sollte die Bilddatei im Projektordner liegen?
Ist das Bild erklärend notwendig oder nur dekorativ?

Formulare als kleiner Ausblick auf spätere Webanwendungen
Wie Eingaben zu HTTP-Anfragen werden, ohne E2 vom Wiki-Kern zu lösen

E1 hat HTTP als Kommunikationsform zwischen Client und Server eingeführt. Formulare zeigen nun, wie eine HTML-Seite selbst Daten für eine solche Kommunikation vorbereitet. Nutzende tragen Werte ein; HTML ordnet diese Werte über Feldnamen; beim Absenden entsteht daraus eine HTTP-Anfrage an ein serverseitiges Ziel.

Im Informatik-Wiki bleibt das ein Ausblick: Ein späteres Formular könnte eine Rückmeldung, einen Vorschlag oder eine Suche vorbereiten. Fachlich steht in E2 aber noch die HTML-Struktur der Eingabe im Mittelpunkt; die serverseitige Verarbeitung folgt in Q2.3.

<form action="/api/beispiel.php" method="post">
  <label for="beitrag">Beitrag</label>
  <input id="beitrag" name="beitrag">
  <button type="submit">Senden</button>
</form>

Bei Formularen ist nicht nur das sichtbare Eingabefeld wichtig. <label> beschreibt die Bedeutung des Feldes für Nutzende. <input> stellt eine Eingabemöglichkeit bereit. name legt fest, unter welchem Feldnamen der eingegebene Wert übertragen wird. Die Eingabe oder ein vorgegebener value wird zum Wert. action bestimmt das Ziel der Anfrage, method die Art der Übertragung. So wird aus einer Eingabe ein strukturierter Datenfluss.

Das Beispiel bleibt bewusst statisch. Es zeigt Formularstruktur, Feldname, Ziel und Methode, aber keine JavaScript-Demo und keine serverseitige Lösung.

Damit schließt sich der Kreis zu E1: Beim Laden einer Webseite war der Browser zunächst Empfänger einer HTTP-Antwort. Mit einem Formular wird dieselbe Webseite zur Eingabeschnittstelle: Der Browser erzeugt nun selbst eine neue HTTP-Anfrage, deren Daten später serverseitig verarbeitet werden können.

`method="get"` und `method="post"` fachlich unterscheiden

Die Übertragungsmethode entscheidet nicht nur technisch über URL oder Request-Body, sondern über die Kommunikationssituation.

<form method="get" action="auswertung.php">
  <input type="text" name="suchbegriff">
  <button>Absenden</button>
</form>

GET eignet sich für Anfragen, die lesbar, wiederholbar und teilbar sein sollen, etwa Such- oder Filteranfragen. Die Parameter erscheinen in der URL, z. B. auswertung.php?suchbegriff=HTML.

<form method="post" action="auswertung.php">
  <input type="text" name="beitrag">
  <button>Absenden</button>
</form>

POST eignet sich für Eingaben, die verarbeitet, gespeichert oder sensibler behandelt werden, etwa Kommentare, Registrierungen oder Datenbankeinträge. Für Q2.3 ist POST besonders wichtig, weil dort Formulardaten serverseitig verarbeitet und in Datenbanken gespeichert werden.

Was passiert im Hintergrund?

<label> und Eingabefeld bilden eine semantische Einheit.
name definiert den Feldnamen für die Übertragung.
value oder die Nutzereingabe wird zum übertragenen Wert.
action und method beschreiben Ziel und Art des Datenversands.
GET: Parameter in der URL, gut für lesbare und teilbare Anfragen.
POST: Daten im Request-Body, geeignet für Verarbeitung und Datenbankoperationen.

Die fachliche Kette lautet bereits hier: Formular → HTTP-Anfrage → Verarbeitung → Ausgabe. In Q2.3 wird diese Kette mit PHP und Datenbanktechnik vollständig umgesetzt.

Grenze dieses Ausblicks

JavaScript kann den Dokumentbaum im Browser verändern und Formulare dynamisch auswerten. Das ist ein möglicher späterer Ausbau, aber nicht das Lernzentrum dieser E2-Seite. Hier bleibt der Schwerpunkt beim strukturierten HTML-Dokument, beim Hypertext und bei gemeinsamer CSS-Gestaltung.

Qualität prüfen und den Anschluss zu Webanwendungen sehen
Warum ein gemeinsames Wiki technische Korrektheit, Verständlichkeit und Konsistenz braucht

Ein Informatik-Wiki bedeutet nicht nur, einzelne Tags zu kennen. Es bedeutet, Inhalte zu planen, Artikelstruktur zu entwerfen, Links fachlich zu begründen, wiederkehrende Gestaltung über CSS aufzubauen, Medien korrekt einzubinden, Quellen sichtbar zu machen und Ergebnisse zu prüfen. Qualität ist deshalb keine bloße Checkliste: Ein gemeinsames Wiki braucht technische Korrektheit, fachliche Verständlichkeit und gestalterische Konsistenz.

Fehler	Wirkung im Browser	Diagnosefrage
schließendes Tag fehlt	Struktur verschiebt sich	Ist die Schachtelung korrekt?
falscher Bild-Dateipfad	Bild erscheint nicht	Stimmt `src` relativ zur Datei?
falsches Linkziel	Link führt ins Leere	Stimmt `href`?
CSS-Klasse falsch geschrieben	CSS wirkt nicht	Stimmen class-Attribut und CSS-Selektor überein?
uneinheitliche Überschriftenstruktur	Artikel wirken unruhig oder unlogisch	Gibt es eine nachvollziehbare Reihenfolge von `h1`, `h2` und Abschnitten?
doppelte oder widersprüchliche CSS-Regeln	Artikel sehen unterschiedlich aus	Gehört die Regel in das gemeinsame Stylesheet?
fehlende Quellen oder Bildnachweise	Informationen bleiben nicht prüfbar	Ist die Herkunft von Text, Bild oder Fakt nachvollziehbar?
tote interne Links	Wiki-Beziehungen brechen ab	Existiert das Ziel relativ zur aktuellen Datei?

Wiki-Artikel werden nicht nur geschrieben, sondern geprüft. Viele Fehler sind Strukturfehler, falsche Ressourcenbezüge, tote Links oder gemeinsame Konventionsprobleme.

Die klare Aufgabentrennung bleibt der rote Faden: HTML strukturiert Inhalte, CSS beschreibt die Darstellung, JavaScript kann den Dokumentbaum im Browser verändern, und PHP verarbeitet Formulardaten serverseitig. Für E2 ist die zentrale Bewegung aber abgeschlossen, wenn aus einzelnen Artikeln ein strukturierter, verlinkter und einheitlich gestalteter Hypertext geworden ist.

HTML: zeichnet Inhalte als Dokumentstruktur aus.
CSS: übernimmt Layout, Farben, Typografie und responsives Verhalten.
Hypertext: verbindet Artikel, Anker, Quellen und Ressourcen.
Formulare: öffnen als Ausblick den Weg zu HTTP-Anfragen und späterer Verarbeitung.
Q2.3: führt Formular, PHP und Datenbanktechnik zu einer vollständigen Webdatenbankanwendung zusammen.

Fachliche Entwicklungslogik E2 → Q2.3

E2 legt die strukturelle Grundlage: saubere HTML-Dokumente, verlinkter Hypertext, external CSS als gemeinsame Gestaltungsschicht und ein kurzer Formularausblick. Q2.3 ergänzt die serverseitige Verarbeitung mit PHP und die persistente Speicherung in relationalen Datenbanken.

Modellierungsfragen zur Qualitätsprüfung

Ist die Überschriftenstruktur im Artikel und im Wiki konsistent?
Sind Tabellen, Listen und Bilder fachlich begründet eingesetzt?
Sind interne Links lebendig und externe Links als Quellen erkennbar?
Gibt es Formatierungen im HTML, die besser ins Stylesheet gehören?
Welche Konventionen muss der Kurs gemeinsam festlegen?

E2 – HTML, Hypertext und CSS

Warum diese Trennung didaktisch so wichtig ist

Artikelthema

Artikelthema

Teilfrage

Öffnende und schließende Tags korrekt lesen

Baumstruktur (DOM-Grundidee) verstehen

Praxis im HTML-Lab: technische Dokumentgrundlage

1) Strukturierende Elemente

2) Tabellen und Listen als Informationsentscheidungen

3) Verweise und Medien im Gesamtsystem

Praxis im HTML-Lab: sichtbare Inhalte modellieren

Praxis im HTML-Lab: einen eigenständigen Artikel entwerfen

D-Book als reales Hypertext-System

Praxis im HTML-Lab: aus Artikeln ein Linknetz entwickeln

CSS-Klassen als Schnittstelle zwischen HTML und CSS

Wiederverwendbare Struktur und zentrale Gestaltungsregel

External CSS als gemeinsame Projektschnittstelle

Praxis im HTML-Lab: gemeinsame Darstellung entwickeln

Ressourcenpfade und Dateiorganisation systematisieren

Praxis im HTML-Lab: Medien verantwortlich integrieren

method="get" und method="post" fachlich unterscheiden

Was passiert im Hintergrund?

Praxis im HTML-Lab: Wiki-Beitrag integrieren und freigeben

`method="get"` und `method="post"` fachlich unterscheiden