§3.1DemoMount – live

Die Arbeitsteilung ist die übliche des Pakets: Das Mount-Markup (Bühne, Controls-Slot, Bildunterschrift-Slot) kommt aus dem Paket; Demo-Modul und Loader gehören der Site. Diese Site hält ihren Loader in src/lib/demo-loader.ts und ruft mountAllDemos() einmal aus dem Layout auf; der Aufruf läuft auf jeder Seite, aber der Chunk eines Demo-Moduls wird nur für eine Seite geladen, die einen [data-demo]-Mount trägt.

Eine Demo, die Zeigereingaben auf ihrem Canvas entgegennimmt, übergibt interactive – die Bühne beansprucht dann Touch-Gesten und zeigt ein Fadenkreuz. Diese hier ist passiv (nur Rendern), lässt das Flag also weg, und ein Wisch über den Canvas scrollt weiterhin die Seite. Sie zeichnet die Interferenz zweier Wellenquellen mit dem Tusche-Token der Seite selbst und folgt damit dem Theme:

Demo · Interferenz zweier Wellenquellen

Demo · Interferenz zweier Wellenquellen

Zwei Punktquellen senden Kreiswellen aus; wo Berg auf Berg trifft, sammelt sich die Tusche, wo Berg auf Tal trifft, scheint das Papier durch. Schalte das Theme um – die Demo tuscht sich aus den lebenden Tokens neu ein.

Der Modulvertrag ist ein einziger Default-Export, mount(ctx), der eine Aufräumfunktion zurückgibt; wie der Loader Modul-ids wie waves/interference auflöst, ist Sache der Site (hier: import.meta.glob).

§3.2Seitenmobiliar

Die übrigen Komponenten rahmen eine Notiz, statt sie zu füllen:

• Hero eröffnet eine Notiz: Kicker, Display-Titel, eine Einleitung, die durch die volle Markdown-Pipeline geht, eine Meta-Zeile und ein optionales tocLabel, das der Seitenleiste eine unnummerierte „Intro“-Zeile hinzufügt. Das Frontmatter-title der Notiz bleibt der kurze kanonische Name für <title> und Karten; der Titel des Heros darf lang sein.
• PartHero eröffnet ein Kapitel eines Hubs – der Kopf dieser Seite. Sein Kicker wird nie getippt: Die Route reicht die Kapitelbeschriftung „Teil III · …“ als props.partLabel herein.
• Part teilt eine lange einseitige Notiz in Teile; das Nummerierungspreset macht daraus die Gruppenzeilen „PART II · …“ der Seitenleiste. Das volle Programm ist so geschnitten.
• HubCard und .hub-grid sind die Startkarten eines Hubs, .path sein Lesepfad-Kasten – beide auf der Übersicht dieser Galerie.
• LocalToc rendert eine Sprungliste in der Seite; es akzeptiert beide ToC-Formen, die die zwei Nummerierungspresets erzeugen, und versteckt sich unterhalb eines konfigurierbaren Minimums. Unten live, am ToC dieses Kapitels.
• SidebarMemory hält eine scrollende Seitenleiste über Seitenwechsel hinweg dort, wo der Leser sie gelassen hat, und zentriert den aktuellen Eintrag (per Default [aria-current="page"]), wann immer er sonst aus dem Blick geriete. In die Scrollbox der Seitenleiste legen, nach dem Navigations-Markup; es läuft vor dem ersten Paint, die Leiste blitzt also nie oben auf. Die Seitenleiste dieser Demo trägt es.
• LineageSvg rahmt eine handgezeichnete SVG (eine Methoden-Ahnentafel, ein Taxonomiebaum) als Karte – eine steht unten.
• PageFooter ist das Kleingedruckte am Fuß einer Notiz – die Zeile unter jeder Notiz hier.
• Die Stöber-Bausteine stehen im Wiki-Kapitel; die Markdown-Seite der Galerie ist Das volle Programm.

§3.3LocalToc und LineageSvg, live

LocalToc, gefüttert mit dem Build-Zeit-ToC dieser Seite – dieselben Daten, die die Seitenleiste konsumiert, der Notiz als props.toc übergeben:

Und LineageSvg um ein handgesetztes Diagramm, vollständig in semantischen Tokens getuscht, sodass es auf beiden Themes sitzt:

§3.4Mobiliar ohne Komponente

Ein paar Stücke sind schlichte Klassen in base.css, für Sites, die sie aus dem eigenen Layout rendern oder als HTML in den Fließtext schreiben: