HTML-Dokumente und -Seiten

Was macht HTML-Dokumente und -Seiten?

Was Sie erstellen

Eine eigenständige .html-Datei. Speichern Sie jede ausgelieferte Datei in ~/.opencode/html/<slug>.html, einschließlich Überarbeitungen. Erstellen Sie das Verzeichnis mit mkdir -p ~/.opencode/html, falls nötig. Streuen Sie die Ausgabe nicht über das Repository, den Desktop oder temporäre Verzeichnisse.

Die Datei lässt sich von der Festplatte öffnen und arbeitet offline. Betten Sie CSS, JavaScript, Bilder und Diagramme ein. Verwenden Sie keine externen Assets, Netzwerkanfragen, Build-Schritte oder Paketinstallationen.

Diese Fähigkeit stellt ein Standard-Stylesheet und einfache Ausgaberegeln bereit. Der Komponentenkatalog ist ein Ausgangspunkt, keine Einschränkung dessen, was der Agent darstellen kann.

Schnellpfad: Schreiben → Anzeigen → Iterieren

1. Lesen Sie die Quelle und components/shell.html.
2. Lesen Sie nur die Komponenten, die für den Inhalt benötigt werden.
3. Schreiben Sie die Datei mit einem Stylesheet-Platzhalter.
4. Ersetzen Sie den Platzhalter durch den Inhalt von styles/base.css wörtlich. Fügen Sie bei Bedarf ein Skin hinzu.
5. Zeigen Sie die Datei mit tools.browser.preview über das execute-Werkzeug an.

Schreiben Sie zuerst das nützliche Dokument. Verwandeln Sie eine einfache Seite nicht in ein Validierungsprojekt. Beheben Sie sichtbare Probleme, wenn sie auftreten. Überarbeiten Sie dieselbe Datei, es sei denn, eine separate Version wird angefordert.

Zusammensetzen und erweitern

• Verwenden Sie Komponenten-Markup wieder, wenn es passt. Behalten Sie vorhandene c--Klassen bei, damit das Stylesheet weiterhin angewendet wird.
• Bauen Sie Layouts mit .c-wrap, .c-section, .c-stack, .c-grid, .c-split, .c-rail und .c-card.
• Fügen Sie Markup, CSS, Inline-SVG oder Vanilla-JavaScript hinzu, wenn der Katalog die Aufgabe nicht abdeckt.
• Bevorzugen Sie die --c-*-Token für benutzerdefiniertes Styling. Halten Sie Überschreibungen nach dem Standard-Stylesheet.
• Verwenden Sie benutzerdefinierte Eigenschaften für routinemäßige Anpassungen, wie z. B. style="--v: 62%" auf einem Balken.

Es gibt kein Limit für benutzerdefinierten Code. Halten Sie Erweiterungen so einfach wie die Aufgabe erlaubt. Bearbeiten Sie nicht die Fähigkeit selbst und fügen Sie keine gemeinsame Komponente nur für ein einziges Dokument hinzu.

Stylesheets: Austauschbare Designsprachen

Datei	Rolle
styles/base.css	Vollständiges Standard-Design. Markierung: /* html-skill: standalone */.
styles/editorial.css	Skin: warmes Papier, Serifenschrift. Markierung: /* html-skill: skin */.

Regeln:

• Fügen Sie das gewählte Stylesheet wörtlich zwischen <style>-Tags im <head> ein. Setzen Sie dokumentspezifische Überschreibungen danach, anstatt die eingefügte Kopie zu bearbeiten.
• Ein Standalone-Stylesheet wird allein verwendet. Ein Skin wird nach base.css eingefügt – Skins überschreiben nur Token und selektive Regeln; das Markup bleibt identisch.
• Ein Skin-Wechsel sollte keine Markup-Änderungen erfordern. Erweiterungen können eigenes Markup und eigene Klassen hinzufügen.
• So fügen Sie eine Designsprache hinzu: Kopieren Sie styles/editorial.css, überschreiben Sie zuerst die Token (--c-bg, --c-ink, --c-accent, --c-font-*, --c-radius-*, --c-measure), und beheben Sie dann alles, was immer noch falsch aussieht. Geben Sie ihr den skin-Marker, es sei denn, sie ersetzt wirklich jede Regel, dann standalone.

Dokumentenaufbau

Beginnen Sie mit components/shell.html. Befolgen Sie diese Ausgaberegeln:

• genau eine <h1>, die mit dem <title> übereinstimmt;
• <title> und <meta name="description"> geben an, was das Dokument ist;
• <meta name="color-scheme" content="light dark"> und das Theme-Skript vor dem ersten Rendern im <head> – vor dem ersten Paint, sonst flackert die Seite;
• Skip-Link zu <main id="main">;
• Abschnitte sind <section class="c-section" id="…">; IDs sind stabil und menschenlesbar;
• ein Inhaltsverzeichnis (components/navigation.html), wenn es die Navigation unterstützt, mit allen vorhandenen Linkzielen;
• Theme-Umschalter und Footer, es sei denn, das Format ist ein reines Druckhandout.

Inhaltsregeln

• Überschriftenebenen tragen die Struktur. Wählen Sie niemals eine Ebene wegen ihrer Größe.
• Geben Sie bei langen Dokumenten jeder h2/h3 einen Ankerlink (.c-hlink).
• Prosa folgt den Schreibpräferenzen des Benutzers. Klar, direkt, eine Idee pro Absatz. Entfernen Sie Füllwörter und werbliche Adjektive.
• Maskieren Sie <, >, & in jedem <pre>.
• Tabellen benötigen <thead>, und Zahlen werden mit .c-num rechtsbündig ausgerichtet.
• Jedes <img> hat alt. Belegbilder erhalten eine .c-figure-Beschriftung.
• Dateiname: kurz, beschreibend, mit Bindestrichen – produktions-finalisierung.html, commits-2026-09-22.html, api-einstellungen-erklaerung.html.

JavaScript

Verwenden Sie die Komponentenblöcke für Theme, Druck, Kopieren, Navigation, Dialoge, Filter, Tabs und Animationen. Fügen Sie nur die Funktionen ein, die das Dokument verwendet.

Benutzerdefiniertes Vanilla-JavaScript ist erlaubt. Halten Sie es inline und offline. Fügen Sie keine Frameworks hinzu und laden Sie keine Daten. Wesentliche Inhalte müssen auch ohne JavaScript lesbar bleiben.

Animation und Barrierefreiheit

• prefers-reduced-motion wird von base.css beachtet; JS, das animiert, muss es ebenfalls prüfen (der Counter-Block zeigt das Muster).
• Sehenswürdigkeiten (header, nav, main, footer) und aria-label auf jedem nav.
• Fokus-Zustände stammen aus dem Stylesheet; entfernen Sie niemals Outline.
• Entwerfen Sie Mobile-First. Bei 360px Breite hat die Seite keine horizontale Bildlaufleiste. Nur .c-table-wrap, Codeblöcke, Diffs, Terminals und .c-tabs-nav dürfen intern scrollen (overflow-x: auto stammt aus dem Stylesheet).
• Popups (.c-drop-body, Mini-Rail-TOC, Tooltips) bleiben innerhalb von calc(100vw - 2rem). Touch-Ziele sind mindestens 24px in jeder Dimension.
• Wickeln Sie jede <table> in .c-table-wrap ein. Bevorzugen Sie einfaches .c-grid (auto-fit), es sei denn, feste Spalten sind erforderlich.

Diagramme

Betten Sie SVG inline in einen .c-shot-Rahmen (components/media.html) oder als data:image/svg+xml;base64,-URI ein. Verwenden Sie data:image/png;base64, für PNG-Bilder. Verknüpfen Sie keine separaten Bilddateien.

Leichte Überprüfung

Zeigen Sie die Datei einmal an. Korrigieren Sie offensichtliche Layout- oder Inhaltsprobleme. Führen Sie standardmäßig keinen Checker, Screenshot-Matrix oder wiederholtes Audit durch. Verwenden Sie gezielte Prüfungen, wenn der Benutzer darum bittet oder ein bestimmtes Problem diagnostiziert werden muss.

python3 <skill-verzeichnis>/scripts/check.py DATEI.html ist eine optionale Diagnose für Markup, Klassen, Überschriften, Anker, Code-Escaping und einige Asset-Referenzen. Es ist kein Auslieferungstor oder Nachweis für Offline-Verhalten oder Barrierefreiheit.

Halten Sie Geheimnisse und private Informationen fern, es sei denn, der Benutzer bittet ausdrücklich darüber deren Aufnahme. Wenn die Vorschau nicht geöffnet werden kann, geben Sie den Dateipfad an und geben Sie an, dass die Darstellung nicht überprüft werden konnte.

Dateien

Pfad	Inhalt
styles/base.css	Kanonisches Stylesheet: Tokens, Theme, Reset, alle Komponenten.
styles/editorial.css	Skin: Serife, warmes Papier.
components/shell.html	Grundgerüst, Kopfzeile, Fußzeile, Theme, Druck.
components/layout.html	Container, Grids, Regionen, Karten.
components/reading.html	Überschriften, Prosa, Zitate, Hervorhebungen, Bewertungen, Fußnoten.
components/evidence.html	Codeblöcke, Diffs, Terminals, Chips, Kopier-JS.
components/data.html	Tabellen, Statistiken, Balken, Messgeräte, Zeitlinien, Vergleiche.
components/navigation.html	Inhaltsverzeichnis, Seitenleiste, Brotkrumen, Seitennummerierung, Scroll-Spy-JS.
components/interaction.html	Akkordeon, Dialog, Tooltip, Dropdown, Filter, Tabs.
components/forms.html	Felder, Auswahlmöglichkeiten, Schaltflächen, Validierungszustände.
components/media.html	Abbildungen, Screenshots, Diagramme, Einbettungen.
components/motion.html	Einblendungen, Zähler, Laufschrift, Folien.
specimen.html	Jede Komponente gerendert – die visuelle Referenz.
scripts/check.py	Optionale Markup-Diagnose.