Diagramme ohne Browser-Laufzeit
Contentkit rendert helle und dunkle Diagramme reproduzierbar auf dem Server, veröffentlicht statische SVGs und behält Markdown-Tabellen als zugängliche Quelldaten.
Der Browser eines Report-Lesers führt keinen Chart-Code aus. Statt einer clientseitigen Diagrammbibliothek lädt er eine statische Darstellung. Contentkit erzeugt serverseitig eigenständige helle und dunkle SVG-Dateien. Die im Markdown verfasste Tabelle bleibt als zugängliche Quelle der dargestellten Daten erhalten.
Teil 12 der Serie „Contentkit – Publishing für Maschinen“.
Aktualisiert und geprüft am 18. August 2026.
Diese Architektur wirkt zunächst wie eine Leistungsoptimierung. Sie ist vor allem eine Entscheidung über Reproduzierbarkeit und Barrierefreiheit: Ein Bericht soll vollständig lesbar bleiben, ohne dass eine clientseitige Diagrammbibliothek geladen wird. Die Visualisierung ist dabei eine Ausgabe der zugrunde liegenden Daten, keine zweite Datenquelle neben ihnen.
Vier Rollen, eine Quelle
Ein Contentkit-Report trennt vier Rollen.
Das semantische HTML trägt die vollständige Information. Für die Diagramme benötigt es weder JavaScript noch eine Browser-Laufzeit.
Die Markdown-Tabelle bleibt als zugängliche Quelle erhalten. Sie verschwindet nach dem Rendern nicht und enthält weiterhin die Kategorien und Werte, auf denen die Visualisierung beruht.
Das SVG ist die kanonische statische Repräsentation der aufgelösten Komposition. Es wird auf dem Server gerendert und als Datei veröffentlicht.
PNG existiert als ausdrücklich angeforderte deterministische Rasterausgabe. Es ist kein automatischer Nebeneffekt, sondern eine gezielte Ausgabe für Abnehmer, die kein Vektorformat verarbeiten.
HTML, Tabelle, SVG und optionales PNG haben getrennte Aufgaben. Eine Änderung am SVG-Renderer definiert weder die Quelltabelle noch die Semantik des HTML-Dokuments neu.
Der Renderer läuft auf dem Server
Im Markdown stehen die Daten als Tabelle neben den Angaben für ihre Darstellung:
:::chart{type="bar" title="Audit findings" description="Confirmed findings by severity" unit="findings"}
| Severity | Count |
|---|---:|
| Critical | 1 |
| High | 4 |
| Medium | 11 |
| Low | 19 |
:::
Der serverseitige Renderer erzeugt daraus die statische Komposition. Der Autorenvertrag beschreibt Daten und Darstellungsabsicht, hängt aber nicht von einer Diagrammbibliothek im Browser ab.
Andere Informationsblöcke müssen deshalb nicht ebenfalls als Grafik ausgegeben werden. SVG bildet Achsen und Proportionen statisch ab. Für gewöhnlichen Text und semantisch strukturierte Inhalte bleibt HTML das passende Format.
Reproduzierbare Ausgabe statt Laufzeitzufall
Ein rein clientseitig gerendertes Diagramm wird erst beim Seitenaufruf zusammengesetzt. Damit hängt die Darstellung von Code ab, der zu diesem Zeitpunkt geladen und ausgeführt wird. Für einen Stichtagsbericht ist eine statische Ausgabe besser überprüfbar: Die veröffentlichte Darstellung steht gemeinsam mit den zugrunde liegenden Daten fest.
Contentkit rendert die aufgelöste Komposition deshalb reproduzierbar auf dem Server. Die kanonische Ausgabe ist ein SVG; ein PNG wird nur auf ausdrückliche Anforderung erzeugt.
Damit lassen sich Tabelle und Darstellung einander zuordnen. Die Tabelle dokumentiert die Werte, während das SVG deren konkrete visuelle Darstellung festhält.
Helle und dunkle SVGs
Contentkit erzeugt eigenständige helle und dunkle SVG-Darstellungen. Beide Varianten werden serverseitig aufgelöst und als statische Dateien veröffentlicht.
Der Browser muss dafür weder die Daten erneut auswerten noch eine Diagrammbibliothek ausführen. Die beiden Dateien sind fertige Ausgaben derselben Komposition für unterschiedliche Farbschemata.
Die Tabelle bleibt die überprüfbare Quelle
Ein Diagramm verdichtet Daten und verbirgt dabei Details. Contentkit entfernt die im Markdown verfasste Tabelle deshalb nicht. Sie bleibt als semantische und zugängliche Quelle erhalten.
Die Tabelle liegt als Quelle in der Markdown-Revision vor; das SVG ist eine daraus abgeleitete Ausgabe. Wer die Zahlen weiterverarbeiten will, liest die Tabelle. Das Auslesen der SVG-Geometrie würde dagegen Rundungen, Skalierungen und Layoutentscheidungen als Quelldaten behandeln.
Selbst wenn eine Visualisierung in einem späteren Verarbeitungsschritt nicht verwendet werden kann, stehen die zugrunde liegenden Daten weiterhin in einer gewöhnlichen tabellarischen Struktur zur Verfügung.
Responsives HTML teilt den Vertrag, nicht das Markup
Neben der statischen SVG-Ausgabe existiert responsives HTML derselben Komposition. Beide verwenden denselben semantischen Vertrag. Das HTML ahmt dabei kein SVG-Markup nach, sondern stellt die Inhalte mit den Mitteln des Dokuments dar.
Das kanonische SVG bildet die aufgelöste statische Komposition ab. Beide Ausgaben beruhen auf derselben semantischen Grundlage, übernehmen aber nicht gegenseitig ihre interne Struktur.
Grenzen des statischen Ausgabepfads
Eine statische Visualisierung steht zum Veröffentlichungszeitpunkt fest. Sie stellt zugrunde liegende Daten reproduzierbar dar, bietet aber keine frei veränderbare Abfrageoberfläche.
Die hier veröffentlichten SVG- und PNG-Dateien bieten selbst keine frei wählbaren Zeiträume, Drill-downs oder Tooltips. Solche Anforderungen benötigen eine interaktive Anwendung mit eigenem Zustands- und Datenmodell. Ein statischer Report verfolgt ein anderes Ziel: Er hält eine konkrete Aussage und ihre Datengrundlage in einer stabilen Ausgabe fest.
Diese Grenze ist auch für die Modellierung relevant. Daten müssen vor der Veröffentlichung so ausgewählt und aggregiert sein, dass Diagramm und Tabelle die beabsichtigte Aussage tragen. Eine Visualisierung sollte fachliche Entscheidungen nicht durch beliebige Interaktion an den Leser delegieren.
Beispiel: ein Stichtagsbericht mit Prüfern
Ein monatlicher Sicherheitsbericht enthält Befunde nach Schweregrad, Behebungszeiten und offene Ausnahmen. Die Seite ist für eine festgelegte Empfängergruppe bestimmt und wird zusätzlich archiviert.
In einem möglichen Ablauf erzeugt ein Agent den Text aus bestätigten Ergebnissen und liefert die Tabellen. Eine vorgelagerte, vom Publikationssystem unabhängige Prüfung könnte Summen im Kennzahlenfeld mit den Tabellenwerten vergleichen. Contentkit erzeugt anschließend helle und dunkle SVGs; die Quelldaten bleiben in den Tabellen erhalten.
Für Empfänger ist der Bericht ohne clientseitige Diagrammbibliothek vollständig lesbar. Prüfer können die konkreten Werte in der Tabelle nachvollziehen, statt sie aus Balken oder Linien rekonstruieren zu müssen.
Wird ein falsch klassifizierter Befund korrigiert, bildet die geänderte Tabelle die Grundlage für eine neue Ausgabe. Der Archivprozess sollte deshalb nicht allein eine visuelle Exportdatei verwahren, sondern auch die zugehörigen Quelldaten. So bleiben sowohl die veröffentlichte Darstellung als auch ihre Datengrundlage prüfbar.
Was der Verzicht auf Browser-Laufzeit betrieblich bedeutet
Ein clientseitiges Chart-Paket muss im Browser verfügbar sein, geparst und ausgeführt werden. Es bringt eigene Abhängigkeiten mit und kann sein Verhalten zwischen Versionen ändern. Contentkit verlagert die Diagrammerzeugung auf den Server und veröffentlicht das Ergebnis als statische Datei.
Die Reportseite referenziert für Diagramme keine clientseitige Diagrammbibliothek. Ihre vollständige Information steht im semantischen HTML und in den erhaltenen Tabellen zur Verfügung. Das SVG liefert die kanonische visuelle Ausgabe.
„Keine Browser-Laufzeit“ bezieht sich auf die vollständige Information des Berichts und seine Diagrammdarstellung. Sie benötigen kein JavaScript.
Fazit
Für Stichtagsberichte, Prüfunterlagen und archivierte Veröffentlichungen ist die feste Zuordnung zwischen Quelldaten und Darstellung wichtiger als freie Interaktion. Frei abfragbare Daten gehören in eine Anwendung mit eigenem Zustands- und Datenmodell.
Weiterführende Quellen
- Contentkit Reports: Ausgabe, Barrierefreiheit und Sicherheit
- Contentkit Information Blocks
- Contentkit Visual Compositions
Wie fandest du diesen Beitrag?
Kommentare