Framework vs. Konsumenten

Elements, Layouts, Components, Sections und Templates können Lieferumfang sein, weil sie inhaltsfrei sind. Eine Surface kann das nie: Sie ist die eine konkrete Seite mit konkretem Inhalt — immer das Endprodukt. Für Anwendungsseiten (Tür 1) wird gar keine Surface gebraucht; sie ist das Dateiformat der Tür 2.

Kurzformel: Framework = Wortschatz und Satzmuster · Surface = der gesprochene Satz (immer deiner, immer Konsument).

Merksatz: Layout = wie angeordnet · Section = was für ein Block · Template = wo auf der Seite · Surface = diese eine Seite mit diesem Inhalt.

Bootstrap liefert Grid, Elements und Components — aber keine Templates. Das ist keine Design-Entscheidung, sondern eine technische Grenze: Bootstrap ist nur CSS, ein „Template" kann dort nur ein Copy-Paste-HTML-Beispiel sein. Und eine Kopie ist tot — kein Update erreicht sie, jede Kopie driftet. Deshalb können Bootstraps Examples nur Demos sein.

Invisible hat diese Grenze nicht: Weil die Sprache Daten sind statt Markup, wird ein Template als versionierte Definition ausgeliefert — zentral, updatebar, referenziert statt kopiert. Was Bootstrap nur als Demo abgeben kann, liefert Invisible als Framework-Bestandteil.

• Props fließen abwärts in Renderer hinein; HTML fließt aufwärts — das Ergebnis wandert eine Ebene höher in einen Slot. HTML entsteht ausschließlich in der Render-Pipeline, nie beim Aufrufer.
• Muss der Empfänger den Inhalt verstehen (Tabellenzelle: Typ prüfen, Badge delegieren, Link bauen) → er bekommt Daten; der Component-Renderer delegiert intern an die zentrale Definition (ui.badge …).
• Muss der Empfänger nur platzieren (Template-Slot) → er bekommt Pipeline-HTML.
• Nie HTML als Datenformat übergeben (vorgerenderte Strings in Zellwerten): das reißt Escaping, Theme und Validierung auf.

Die Arbeitsteilung: Das Framework liefert die Fähigkeiten — generische Sections mit Slots und Vorräten, Components, Layouts, Tokens. Der Konsument komponiert: Er zieht den Hero in die Seite, den Code-Block in den Hero-Slot, wählt den Hintergrund aus dem Vorrat — im Builder per Drag & Drop, an Tür 1 als PHP-Komposition. Seine Komposition friert er über „Als Block speichern" als seine Custom-Section ein, sein Seitengerüst als seine Vorlage — künftig im Projekt-Katalog, nie im Lieferumfang.

Merksatz: Props = was die Instanz darf · Token-Props = wo sie gestalten darf · Komponenten-Tokens = was der Component-Bauer umverdrahten darf.

Pflicht und umgesetzt (2026-08-10): JEDE Definition liefert ihre themebaren Werte (Farben, Radien, Schatten, Fokus-Ring) als eigene Komponenten-Tokens — flächendeckend nachgerüstet, maschinenlesbar, ohne Markup-Eingriff umverdrahtbar. Ein blockierendes Palette-Gate im Build erzwingt die Schichtung: Referenz-Palette darf nur in ein lokales Komponenten-Token fließen (Marken-Umverdrahtung), nie direkt in eine Eigenschaft — dort griffe kein Theme mehr. Die Kette ist immer dreigliedrig: --card-radius: var(--radius-surface) (Ebene 3 → Semantik) → --radius-surface: var(--radius-md) (Semantik → Referenz) — nie eine Stufe überspringen, denn die Mitte ist der Theme-Hebel. Die Stellschrauben jeder Definition stehen maschinenlesbar in der Registry (vom Build aus dem CSS generiert — keine Hand-Liste im Manifest, das wäre eine zweite Wahrheit) und sind in der Galerie-Detailansicht als Tabelle sichtbar.

An Tür 1 erzwingt das Framework nichts — Aussteigen ist auf jeder Ebene erlaubt. Aber jede Sprosse abwärts kostet Garantie:

Regel für Sonderfälle: Vorlage oder Vorrat erweitern (neue Version — alle profitieren) statt daneben bauen. Der selbstgebaute Sonderfall von heute ist die Altlast von morgen.