# Responsive heißt neu komponieren
URL: https://www.mikebild.dev/de/blog/responsive-heisst-neu-komponieren/
In diesem Beispiel passen 320 Pixel, zwölf Prozessschritte und eine angeforderte waagerechte Darstellung nicht zusammen. Eine Rendering-Engine kann die Schrift so lange verkleinern, bis alles in einer Zeile steht. Der Text wäre noch gerendert, aber nicht mehr verlässlich lesbar. ContentKit wechselt deshalb die Anordnung, bevor die Schrift weiter schrumpft.
*Teil 15 der Serie „ContentKit – Publishing für Maschinen“.*
Responsive Design wird bei Infografiken oft mit proportionalem Schrumpfen verwechselt. Das funktioniert für ein Foto, dessen Details auch kleiner noch erkennbar bleiben. Bei Text, Achsen, Karten und Beziehungen verändert Schrumpfen dagegen die Lesbarkeit. ContentKit behandelt Breite und Höhe deshalb als Eingaben der Komposition. Ein Pattern kann auf einen schmalen Container mit einer anderen, semantisch gleichwertigen Form reagieren.
## Der Container ist genauer als der Bildschirm
Eine Desktop-Seite kann einen schmalen Inhaltsbereich besitzen. Eine mobile Seite kann ein Diagramm über die gesamte Breite zeigen. Die Fensterbreite allein sagt deshalb wenig darüber aus, wie viel Platz ein Baustein tatsächlich hat. ContentKit löst Patterns mit dem effektiven Container auf.
```json
{
"viewport": { "width": 1440, "height": 900 },
"container": { "width": 620, "height": 760 },
"context": "article-main",
"density": "balanced",
"outputs": ["html", "svg"]
}
```
Zur Entscheidung gehören außerdem Elementzahl, Textbudgets, verfügbare Höhe, Einbettungskontext, Ausgabemedium und gewünschte Lesedichte. Ein Pattern, das im Vollbild funktioniert, kann in einer Seitenspalte ungeeignet sein. Die Registry hält daher konkrete Fallbacks für die jeweilige Aussage fest. Ein einzelner globaler Breakpoint würde dafür nicht ausreichen.
```mermaid
flowchart TD
I["Semantischer Inhalt"] --> C["Container und Ausgabe messen"]
C --> E{"Pattern weiterhin geeignet?"}
E -->|ja| L["Layout mit passenden Abständen lösen"]
E -->|nein| F["Semantisch sicheren Fallback wählen"]
F --> L
L --> V["Geometrie und Text im Browser prüfen"]
```
Ein Fallback ändert hier die Anordnung und bewahrt die fachliche Beziehung. Beispielsweise wird ein waagerechter Prozess zu einer senkrechten Folge. Die Reihenfolge aus dem Markdown bleibt dabei die zugängliche Lesereihenfolge für HTML und statische Ausgaben.
## Inhaltsbudgets gehören vor das Rendering
Kein Layout kann unbegrenzt viel Text aufnehmen. Der Pattern-Vertrag nennt deshalb die zulässigen Grenzen für Titel, Elemente und Tabellenspalten. Ein Agent kann diese Angaben bereits vor dem Rendering berücksichtigen.
Das folgende Schema zeigt die Art solcher Grenzen. Die konkreten Werte legt jeweils der Vertrag des gewählten Patterns fest.
```yaml
content_budget:
max_items: pattern-defined
max_title_characters: pattern-defined
max_words_per_item: pattern-defined
max_table_columns: pattern-defined
```
Diese Angaben begrenzen den Suchraum und machen eine Verletzung früh sichtbar. Beim Kompilieren liefert ContentKit strukturierte Diagnosen. Ein Agent kann daraufhin kürzen, ein anderes Pattern wählen oder die Aussage auf zwei Abschnitte verteilen.
Stilles Abschneiden wäre bequemer, aber fachlich gefährlich. Aus „nicht verfügbar“ darf kein unsichtbares „nicht“ werden. Eine URL darf nicht so gekürzt werden, dass zwei verschiedene Ziele gleich aussehen. Eine Tabellenzeile darf im statischen Export nicht verschwinden, ohne dass die ausgelassenen Datensätze ausdrücklich genannt werden.
## Datentyp und Einheit begrenzen die Patternwahl
Responsive Layout hängt nicht allein von der Textlänge ab. Der Wert `12` kann eine Anzahl, einen Prozentwert, einen Geldbetrag oder eine Dauer bezeichnen. Erst Datentyp und Einheit erlauben dem Renderer, eine passende und eindeutige Darstellung zu wählen. Vergleichbare Reihen brauchen kompatible Einheiten; Zeitwerte benötigen eine sortierbare Form und eine davon getrennte Beschriftung.
Diese Semantik wirkt direkt auf die Darstellung. Eine Kalenderansicht benötigt echte Kalendertage, eine zeitliche Abfolge sortierbare Ereignisse und eine Kennzahl ihre Einheit. ContentKit formatiert die Anzeige, errät aber nicht die Bedeutung eines unvollständig beschriebenen Werts.
## Schmale Container brauchen eine andere Anordnung
Auf einem breiten Dashboard können Leserfrage, Einordnung und weitere Entscheidungshorizonte nebeneinander stehen. In einem schmalen Container bleibt der aktuelle Report zuerst; Einordnung, Handlung und weitere Horizonte folgen darunter als einzelne Abschnitte.
Die mobile Fassung zeigt den aktuellen Report zuerst und ordnet Einordnung, Handlung und weitere Horizonte darunter an. Unterstützende Inhalte folgen in Quellreihenfolge und große Vergleichsflächen werden vermieden. Ein Nutzer muss weder zoomen noch horizontale Bereiche erraten.
Bei einem Datendiagramm kann eine andere Entscheidung richtig sein. Eine Rangliste kann auf schmaler Breite weiterhin Balken verwenden, wenn Beschriftungen und Werte untereinander passen. Ein Scatterplot braucht dagegen seine zweidimensionale Fläche. In diesem Fall kann ein größerer vertikaler Ausschnitt, eine kürzere Beschriftung oder eine zugängliche Datentabelle sinnvoller sein als ein vollständig anderes Pattern.
## HTML, SVG und PNG haben verschiedene Stärken
Responsive HTML kann Inhalte im natürlichen Dokumentfluss umbrechen und seine Höhe anpassen. SVG besitzt einen festen Viewport und berechnet seine Geometrie für die angeforderte Größe. PNG ist die statische Rasterausgabe für Systeme, die kein Vektorformat verarbeiten.
```mermaid
flowchart LR
S["Semantic AST und Narrative"] --> H["HTML und CSS
natürlicher Dokumentfluss"]
S --> G["SVG
präzise Geometrie"]
G --> P["PNG
statischer Rasterexport"]
```
Ein Headless-Abnehmer wählt die benötigten Ausgaben ausdrücklich. ContentKit muss nicht alles in SVG pressen, nur weil SVG verfügbar ist. Ebenso wenig sollte eine komplexe Beziehungsdarstellung allein mit verschachtelten `div`-Elementen nachgebaut werden, wenn Linien und räumliche Zuordnung den Kern bilden.
## Lesbarkeit wird als Vertrag geprüft
Ein responsives Ergebnis darf nicht durch immer kleinere Schrift erkauft werden. Pattern-Verträge und die Browserprüfung setzen dafür überprüfbare Grenzen. Überschriften, Kennzahlen, Karten und Abstände werden gemeinsam mit der verfügbaren Fläche geprüft. Die konkreten Schwellenwerte dürfen sich mit Schrift, Pattern und Testbestand weiterentwickeln; die Anforderung an eine lesbare Ausgabe bleibt bestehen.
Diese Regeln verhindern, dass ein formal gültiges Ergebnis mit winzigen Labels durch die Pipeline rutscht. Zusätzlich prüft ein Redakteur Reihenfolge, Gruppierung und Hervorhebung der zentralen Aussage. Lesbarkeit gehört damit zum Vertrag der Ausgabe und wird nicht erst nach dem Rendering beurteilt.
## Browsermessung statt Vertrauen
Die Browserprüfung misst die tatsächlich gerenderte Geometrie. Sie erkennt damit Überlappungen, abgeschnittene Inhalte und falsche responsive Fallbacks an der Ausgabe, statt nur vorher berechnete Koordinaten zu vergleichen.
Die Referenzfälle decken unterschiedliche Container und Informationsmuster in HTML, SVG und PNG ab. Ihre Anzahl ist kein Teil der Architektur. Dauerhaft ist die Verpflichtung, repräsentative Grenzfälle in allen unterstützten Ausgaben zu prüfen.
Die Fälle müssen die Fallbacks tatsächlich auslösen: mit Mindest- und Höchstmengen, langen deutschen und englischen Texten, untrennbaren Token, fehlenden optionalen Inhalten und schmalen Containern. Ein Test, der nur das ideale Desktop-Beispiel öffnet, würde genau die Fehler übersehen, die später auf einem Telefon auftreten.
## Die Entscheidung bleibt für Agenten nachvollziehbar
Fordert ein Agent ein waagerechtes Prozess-Pattern an und ContentKit löst stattdessen einen senkrechten Fallback auf, steht diese Entscheidung im Modell und in den Diagnosen. Der Agent kann seinem Nutzer mitteilen, dass die waagerechte Form wegen Containerbreite und Elementzahl ersetzt wurde. Er soll nicht so tun, als sei jede Präferenz unverändert erfüllt worden.
Der Autor kann den Inhalt beibehalten, die Präferenz ändern oder einen Abschnitt aufteilen. Das Modell nennt die aufgelöste Patternentscheidung und ihren Grund, damit der Wechsel nachvollziehbar bleibt.
## Jede Informationsfamilie braucht eigene Regeln
Ein globales „unter 768 Pixel alles untereinander“ wäre wieder nur eine Layoutschablone. Verschiedene Semantiken verlieren auf unterschiedliche Weise ihre Lesbarkeit. ContentKit bindet responsive Regeln deshalb an das jeweilige Pattern.
Für Prozesse zählen Schrittzahl, Beschreibungslänge und Richtung. Vier kurze Schritte passen häufig waagerecht, acht ausführliche Schritte nicht. Für Vergleiche zählt, ob zwei Seiten als Ganzes oder Kriterium für Kriterium gelesen werden sollen. Eine Matrix kann auf schmaler Breite zu einzelnen beschrifteten Vergleichszeilen werden. Die Zuordnung zwischen Kriterium und Seite muss dabei sichtbar bleiben.
Bei Tabellen ist horizontales Quetschen besonders problematisch. Eine Tabelle kann bei wenigen Spalten ihre Zeilen behalten. Reicht der Platz nicht, wird jede Zeile zu einem beschrifteten Datensatz, in dem Schlüssel, Status und Werte lesbar bleiben. Der ursprüngliche Tabelleninhalt bleibt im HTML und im Headless-Modell erhalten.
Datengrafiken verlangen eine besonders vorsichtige Entscheidung. Balken können untereinander wachsen, ein Scatterplot braucht dagegen seine zweidimensionale Fläche. Wo keine gleichwertige Grafik in den Container passt, muss ContentKit eine zugängliche Datentabelle anbieten oder die angeforderte Darstellung mit einer Diagnose ablehnen.
## Höhe und Zoom verändern den verfügbaren Raum
Eine Komposition kann in der Breite passen und trotzdem in einem begrenzten Einbettungsrahmen zu hoch werden. Deshalb gehört die verfügbare Höhe ebenfalls zur Auflösung. Eine Anwendungsschale in einem vollständigen Fenster hat andere Möglichkeiten als dieselbe Zusammenfassung in einem Bericht. ContentKit darf dabei Dichte und Offenlegung verändern, aber keine wesentlichen Fakten still entfernen.
Browserzoom wirkt ähnlich wie ein schmalerer Container: Der Text wächst, während die verfügbare CSS-Fläche sinkt. Die responsive Auflösung reagiert darauf über den wirksamen Container. Navigation, Karten und Tabellen behalten dabei ihre Lesereihenfolge und dürfen wesentliche Inhalte nicht verlieren.
## Freiraum und Dichte folgen dem Container
Mehr Platz ist nicht automatisch besser genutzt, wenn Inhalt und Leserführung klein in einer Ecke stehen. Umgekehrt macht eine vollständig gefüllte Fläche eine Seite unruhig. Der Layoutresolver arbeitet deshalb mit Abstands- und Dichte-Tokens, Mindestbreiten und einer begrenzten Zahl von Elementen pro Reihe.
Auf breiten Leinwänden darf eine zentrale Aussage mehr Raum erhalten, während unterstützende Fakten kompakter gruppiert werden. Auf schmalen Flächen werden Abstände reduziert, aber nicht wahllos halbiert. Die Hierarchie muss durch Größenverhältnisse, Ausrichtung und Freiraum weiterhin erkennbar bleiben. Genau diese Relationen werden in den Browser-Referenzfällen bei repräsentativen Containerbreiten verglichen.
Eine technisch fehlerfreie Ausgabe darf weder überlaufen noch Informationen abschneiden. Darüber hinaus müssen Reihenfolge, Gruppierung und Abstände die fachliche Hierarchie erkennbar halten. Zusätzliche Fläche ist nur dann sinnvoll genutzt, wenn sie diese Beziehungen deutlicher macht.
## Das ContentKit-Cockpit zeigt Struktur, Ausgabe und Validierung
Die Rendering-Architektur bleibt headless. Anwendungen und Agenten übergeben semantisches Markdown an die ContentKit-API und fordern die benötigten Ausgaben an. Für die menschliche Arbeit besitzt ContentKit zusätzlich ein eigenes Web-Cockpit. Diese Oberfläche verwaltet keinen zweiten Satz von Regeln. Sie verwendet dieselben Serververträge wie die API.
Im Inhaltseditor zeigt das Cockpit drei getrennte Sichten: die erkannte Dokumentstruktur, die serverseitig gerenderte Ausgabe und das Ergebnis der Validierung. Die Vorschau entsteht damit nicht durch einen vereinfachten Markdown-Renderer im Browser. Der Server rendert das Dokument und liefert die strukturierten Diagnosen zurück. Der Editor zeigt diese Validierungsergebnisse an.
Nach dem Speichern kann ein Redakteur eine zeitlich begrenzte Vorschau bauen und gezielt die betroffenen Dokumente auswählen. Vorschau, gespeicherte Revision und späterer Release bleiben getrennte Zustände. Das ist für responsive Kompositionen wichtig: Eine korrekte Patternwahl im Modell reicht noch nicht als Freigabe. Der Mensch muss die konkrete Seite, ihre Leserführung und ihre Darstellung auf schmalen und breiten Flächen prüfen können.
```mermaid
flowchart LR
M["Markdown und Frontmatter"] --> V["Server validiert und rendert"]
V --> C["ContentKit-Cockpit
Struktur, Ausgabe, Diagnosen"]
C --> D["Unveränderliche Revision"]
D --> P["Zeitlich begrenzte Vorschau"]
P --> H{"Menschliche Prüfung"}
H -->|freigegeben| R["Release"]
H -->|Korrektur nötig| M
```
Das Cockpit zeigt Struktur, gerenderte Vorschauseite und Diagnosen über den maschinenlesbaren Produktverträgen. Es verschiebt jedoch keine Verantwortung in den Renderer. ContentKit entscheidet deterministisch, welche Darstellung zulässig ist. Der Redakteur prüft, ob Leserführung, Reihenfolge und Hervorhebung der fachlichen Aussage stimmen.
## Fazit
Container, Inhalt und Ausgabemedium müssen vor der Geometrie aufgelöst werden. Passt die bevorzugte Darstellung nicht, wählt ContentKit einen diagnostizierten, semantisch gleichwertigen Fallback oder lehnt die Anforderung ab. Ein Renderer darf eine unlesbare Wunschdarstellung nicht durch Schrumpfen formal erfüllen. Das Web-Cockpit macht die resultierende Seite samt Diagnosen für die menschliche Prüfung sichtbar. Die konkrete Anordnung darf sich weiterentwickeln; Semantik und Lesereihenfolge bleiben der Vertrag.
## Weiterführende Quellen
- [ContentKit Visual Compositions](https://github.com/MikeBild/contentkit/blob/443906f0c50ceac784a006f9dd92b3c1328b1804/docs/VISUAL_COMPOSITIONS.md)
- [ContentKit Semantic Information Blocks](https://github.com/MikeBild/contentkit/blob/443906f0c50ceac784a006f9dd92b3c1328b1804/docs/INFORMATION_BLOCKS.md)
- [ContentKit-Cockpit: serverseitige Vorschau im Inhaltseditor](https://github.com/MikeBild/contentkit/blob/443906f0c50ceac784a006f9dd92b3c1328b1804/apps/cockpit/src/forms/content/preview.tsx)