FluentUI: Wiki Layout (Doku-Shell, vertieft)

Zurück: FluentUI (Design-System-Bibliothek)

Status: Tier 1 — beschreibt tatsächlich umgesetzten Code. Erstkonsument ist das Template wkbizway (inc/wiki-shell.php plus css/wiki-layout.css, css/area-wiki.css, css/dokuwiki-overrides.css, js/wiki-area.js), aktiv auf allen Seiten mit Area-Profil wiki ({lang}:wiki:*). Quelle der Wahrheit für Implementierungsdetails: wiki-area-shell_inc_wiki-shellphp — diese Seite hier ist die bereichsbezogene Design-System-Referenz: Muster, Verträge und Übernahme-Leitfaden für künftige Konsumenten, keine Implementierungs-Doku.

Referenzvorbild: Doku-Seiten von Google Developers (developers.google.com/style, devsite-Shell) und Microsoft Learn — Inhalt als „Blatt Papier auf einer Mat„, flankiert von Navigations- und Werkzeugspalten.

Eine Dokumentations-Shell für Lese-Seiten: maximal fünf Spalten ab 1024px, die nach außen hin immer „leichter“ werden — innen der Inhalt, daneben Navigation (Doc-Sidebar) und Orientierung (Seiten-TOC), ganz außen zwei schmale Icon-Rails (Werkzeuge/Umschalter). Unterhalb 1024px kollabiert die Shell progressiv (Drawer statt Spalten), unterhalb 768px zur Einspaltigkeit. Kopf- und Fußzeile sind bewusst identisch zur Site-Hülle des jeweiligen Templates (eine Marke, zwei Profile).

Skizze mit maßstäblichen Fugen (6px:10px = live 12px:20px):

Die wk-shell-*-Spalte ordnet die Regionen dem generischen Vokabular aus FluentUI: Basic Layout (vertieft) zu: Topbar/Rails sind dort als „geerbt“ markiert — ein künftiges generisches Shell-Modul baut sie nicht neu, sondern übernimmt diese Umsetzung.

Zwei Extension-Tokens (wkbizway-eigen, definiert in css/tokens.css — nicht Teil des cross-template Styles-Contract):

Dazu: Außenkanten ab 1024px bündig (horizontales Shell-Padding 0 — Rails liegen wie die VS-Code-/Azure-Data-Studio-Activity-Bar direkt an der Viewport-Kante); darunter 1em bzw. 16px (<768px) Randabstand.

Mechanik in zwei Sätzen: Die Abstände liegen nicht auf der Grid-gap-Property (die reserviert ihren Wert auch neben Spalten, die zur Laufzeit auf 0px kollabieren), sondern als Margins der beiden kollabierbaren Spalten („Margin-Ownership„); klappt eine Spalte ein, übernimmt der Inhalt genau den einen Rail-Gap an der frei gewordenen Kante. Vollständige Begründung im Code-Kommentar des @media (min-width: 1024px)-Blocks von css/wiki-layout.css.

Der Inhalt liegt als weiße Karte (max-width: 21cm = DIN-A4-Breite, Token --wk-wiki-content-max-width) mit Schatten auf einer grauen Mat. Beide Flächen sind bewusst eckig (border-radius: 0 an allen Breakpoints): Papier ist rechteckig; die Referenz-CSS von developers.google.com nutzt 2px/0 — praktisch nicht wahrnehmbar, also ist 0 konsistent mit der Referenz. Popover, Buttons und WRAP-Boxen behalten ihre Radien — sie sind nicht Teil der Papier-Fläche.

• Schriftgröße fest 13px (Font-Familie über --wk-wiki-font-body).
• Level-1-Flattening (Google-Developers-Muster): Hat der TOC genau einen Level-1-Eintrag, ist das bei toptoclevel=1 immer ein Duplikat des daneben sichtbaren H1-Seitentitels — seine Titelzeile wird versteckt, die Kindliste beginnt ohne Einzug. Zwei Schutzbedingungen: :only-child (Mehr-H1-Seiten bleiben unberührt) und :not(.mode_admin) (Admin-TOCs haben echte Labels statt Titel-Duplikaten, z. B. „Datenbank:“ der sqlite-Datenbankliste). Es wird nur die Titelzeile versteckt, nie eine Kindliste.
• Leerer TOC (Seite ohne Überschriften) blendet die ganze Spalte aus statt sie leer zu zeigen.

Analog zu VS Codes LayoutClasses (vgl. layout → Sichtbarkeits-Klassen), gesetzt auf .wkbizway-wiki-shell:

js/wiki-area.js (nur auf wiki-Profil-Seiten geladen): Drawer-Steuerung für Doc-Sidebar, Rail und TOC mit einem oder mehreren Trigger-Buttons pro Drawer (der TOC-Umschalter existiert als zwei DOM-Kopien — rechte Rail ab 1024px, linke Rail darunter; CSS zeigt nie beide gleichzeitig, aria-expanded wird auf allen Kopien synchron gehalten). Escape schließt und fokussiert die aktuell sichtbare Button-Kopie (offsetParent-Prüfung zur Laufzeit); Offen/Zu-Zustand optional in localStorage. Wichtig bei DOM-Duplikaten für Breakpoint-Fallbacks: immer eigene Modifier-Klassen je Kopie — eine geteilte Klasse lässt Sichtbarkeitsregeln der einen Kopie versehentlich auch die andere treffen.

1. Direkt wiederverwendbar: Regionsvokabular und Verhaltensverträge dieser Seite (Abstands-Kontrakt, Zustands-Klassen-Ansatz, Flattening-Muster) sowie die generischen .wk-shell-*-Primitives aus wkfluentui/style.css (Sektion WIDGETS).
2. Template-spezifisch (nicht kopieren, sondern analog bauen): wkbizway-*- Klassen, --wk-wiki-*-Extension-Tokens und inc/wiki-shell.php-Markup.
3. Vor eigenen Abstraktionen prüfen, ob die Helper-API (z. B. adminrail, nav, toolbar()) die Aufgabe bereits abdeckt.

• tseed-Falle: Template-CSS-Änderungen rotieren den Cache-Buster nicht — nach jedem Edit conf/local.php touchen (Details: Verifikation).
• CSS-Compiler-Fallen (sitewide fatal): kein */ im Kommentartext (beendet den Kommentar vorzeitig) und kein min()/calc() mit gemischten Einheiten.
• ?t=<template> an css.php ist ein Template-Override, kein Cache-Buster.
• Grid-Track ≠ Elementbreite: Spalten-Margins liegen innerhalb der fixen Tracks — Gap-Änderungen verbreitern das Spalten-Element, nicht die Inhaltsspalte.

• wiki-area-shell_inc_wiki-shellphp — Implementierung (Quelle der Wahrheit)
• FluentUI: Basic Layout (vertieft) — Basic Layout (ADS-Shell) und wk-shell-*-Vokabular
• FluentUI: Admin-Bereich (vertieft) — Admin-Bereich (Aktivitätsleiste, Farbsemantik, Toolbar)
• FluentUI: Design-Tokens · Styles-Contract (--wk-*) — Token-Verträge
• FluentUI: Öffentliche Helper-API — Helper-API (u. a. nav, adminrail)