Des Kaisers neue Kleider: f451 Templates

Des Kaisers neue Kleider: f451 Templates

Anders als im Märchen sind diese neuen Kleider echt. Mit den Releases 1.2.5 bis 1.2.9 bekommt f451 innerhalb von zwei Tagen ein neues Erscheinungsbild, von der Bauart der Tabellen bis zu Randnotizen neben dem Text. Darunter bleibt alles beim Alten. Jede Seite ist weiterhin eine gewöhnliche Markdown-Datei in Git, und keine neue Funktion braucht eine Syntax, die nur f451 versteht.

Bausteine, die anders gebaut sind

Seit 1.2.0 lassen sich Farben, Schriften und Abstände pro Instanz, pro Space und pro Nutzer einstellen. Damit sah eine Werkbank-Vorlage aber nur anders gefärbt aus als eine Editorial-Vorlage, nicht anders gebaut. Version 1.2.5 ändert das mit zwölf Schaltern in einer neuen Gruppe „Bausteine“. Jeder Schalter legt fest, wie ein Element gebaut ist, nicht wie es gefärbt ist.

SchalterWerteBaustein
table-styleopen, framedTabelle offen mit Linie unter dem Kopf oder gerahmt
callout-stylebar, boxHinweisbox mit Balken links oder als Kasten
toc-stylenumbered-progress, barInhaltsverzeichnis nummeriert mit Fortschrittslinie oder am Balken
code-headeroff, onKopfzeile mit der Sprache über Codeblöcken
list-markerdash, discAufzählungszeichen

Das ist ein Auszug, die vollständige Liste steht im Admin Guide. Technisch erzeugt ein Schalter keine CSS-Variable, sondern ein data--Attribut am Wurzelelement der Seite, und nur dann, wenn sein Wert vom Editorial-Standard abweicht. Die fünf mitgelieferten Vorlagen setzen alle Schalter ausdrücklich und übernehmen damit die Bauart ihrer Entwürfe, nicht nur deren Farben.

Mit 1.2.5 hat sich auch das Aussehen ohne Theme geändert. Wer kein eigenes Theme hat, sieht jetzt den Editorial-Entwurf mit offenen Tabellen, Strichen als Listenzeichen und nummeriertem Inhaltsverzeichnis. Das bisherige Aussehen lebt als Vorlage rotecodefraktion weiter. Eine Zeile use: rotecodefraktion in _meta/theme.yaml holt es zurück.

Der Rahmen um die Seite

Version 1.2.6 überträgt dasselbe Prinzip auf den Rahmen der Seite, mit fünf Schaltern in der Gruppe „Rahmen“.

SchalterBestimmt
topbarob es eine Kopfleiste gibt
page-headob über der Seite eine Titelzeile oder eine Werkzeugleiste steht
pane-controlswie Seitenbaum und Info-Leiste ein- und ausgeklappt werden
rail-scrollob die Info-Leiste mitscrollt
status-barob unten eine Statusleiste erscheint

Anders als die Bausteinschalter ändern einige Rahmenschalter das Markup und nicht nur die Gestaltung. Ohne Kopfleiste wandern Marke, Space-Wechsler und Suche in den Kopf des Seitenbaums, Sprache, Hell- und Dunkelmodus und Konto in dessen Fuß. Auch hier ist der Editorial-Entwurf jetzt der Standard, und die Vorlage rotecodefraktion hält den alten Rahmen. Dazu kam ein Filterfeld im Seitenbaum, das für alle Vorlagen gilt.

Ein eigenes Stylesheet pro Repository

Schalter und Tokens decken ab, was f451 vorsieht. Für alles andere gibt es seit 1.2.7 ein eigenes Stylesheet, _meta/theme.css, im Instanz-Repository und in jedem Space-Repository, dazu Schriften im Web-Schriftformat WOFF2 unter _meta/fonts/. Es wird nach dem Betreiber-Stylesheet geladen, erst das der Instanz, dann das des Space.

f451 prüft das Stylesheet beim Hochladen und beim Lesen, etwa auf @import, URLs, verbotene Konstrukte und die Größe. Eine gestalterische Prüfung gibt es nicht. Wer sich die Seite ohne Stylesheet ansehen will, hängt ?ohne-stylesheet an die Adresse. Weil das Stylesheet wie alles andere im Repository liegt, gelten auch hier Rechte, Historie und Review aus Git.

Fußnoten, die am Rand stehen

Den Umbau des Erscheinungsbilds schließt 1.2.8 ab. Der Editorial-Entwurf setzt Randnotizen neben den Text, wie in einem gut gesetzten Buch. Markdown kennt aber keine Randnotiz. Die naheliegende Lösung wäre eine eigene Syntax gewesen, ein Block mit einem Schlüsselwort, den nur f451 versteht.

f451 nimmt stattdessen gewöhnliche Fußnoten aus GitHub Flavored Markdown (GFM), der Markdown-Variante von GitHub.

Kernel updates need a reboot.[^reboot]

[^reboot]: Live patching covers security fixes only, not new features.

Ein neuer Bausteinschalter marginalia entscheidet, wo die Notiz erscheint. Mit margin steht sie im Rand neben dem Absatz, der zum ersten Mal auf sie verweist. Mit list stehen alle Notizen als gestaltete Liste am Ende der Seite. Die Vorlagen Editorial, Fokus und Klar & Warm setzen Randnotizen, System / Raster, Werkbank und Rotecodefraktion die Liste.

Eine f451-Seite im Editorial-Theme: Die Fußnoten 1 und 3 stehen als Randnotizen neben ihrem Absatz, Fußnote 2 mit zwei Absätzen steht in der Liste am Seitenende.

Die Fußnoten 1 und 3 stehen im Rand neben dem Absatz, der auf sie verweist. Fußnote 2 hat zwei Absätze und bleibt deshalb in der Liste am Seitenende.

Die Notiz hängt an der Breite der Lesespalte, nicht an der des Fensters. Ist die Spalte schmaler als 32 rem, etwa mit ausgeklapptem Seitenbaum und Info-Leiste oder auf dem Telefon, steht dieselbe Notiz als kleiner Block unter ihrem Absatz. Die Ziffer im Text springt zur Notiz, die Ziffer an der Notiz zurück. Breite und Abstand der Randnotiz lassen sich über layout-note-w (10 bis 20 rem) und layout-note-gap (0 bis 2 rem) einstellen. Beide Tokens waren seit 1.2.5 gesperrt, weil es die Randnotiz noch nicht gab.

Fußnoten mit mehreren Absätzen, einer Liste oder einem Codeblock passen nicht in einen schmalen Rand. Sie bleiben immer in der Liste am Seitenende.

Keine eigene Syntax, aus Prinzip

Die Entscheidung für GFM-Fußnoten folgt dem Grundsatz, mit dem f451 angetreten ist. Die Seiten sind CommonMark, der formale Standard für Markdown, mit den GitHub-Erweiterungen, ohne Syntax eines Herstellers. Eine Fußnote zeigt jeder andere Renderer korrekt an, Forgejo, GitHub, Obsidian, Hugo, am Ende der Seite. f451 setzt sie lediglich an eine andere Stelle, wenn das Theme es so will.

Wer die Seite später aus f451 herausnimmt, verliert also nichts. Die Notiz wandert vom Rand ans Ende, ihr Inhalt bleibt. Eine eigene Randnotiz-Syntax hätte genau das Gegenteil bewirkt, nämlich Dateien, die außerhalb von f451 mit unverständlichen Blöcken übersät sind.

Technisch bleibt das gespeicherte HTML im Index für beide Schalterwerte dasselbe Standard-HTML. Die Versetzung in den Rand geschieht erst beim Ausliefern der Seite, weil der Schalter je Instanz, Space und Nutzer verschieden sein kann.

Bei der Arbeit an den Randnotizen fielen nebenbei zwei Fehler auf, die auch ohne Randnotiz bestanden. Die Überschrift der Fußnotenliste war englisch, bekam bei nummerierten Kapiteln eine Ziffer und verlor ihre ID, sodass die Verweise für Screenreader ins Leere zeigten. Der Review-Diff zeigte zudem Fußnotenverweise als rohe Zeichenfolge [^1] und ihre Definition als leeren Block. Beides ist in 1.2.8 behoben.

Fußnoten auch im WYSIWYG-Editor

Bis 1.2.8 öffnete der Editor eine Seite mit Fußnoten nur im Markdown-Modus. Version 1.2.9 vom selben Abend schließt diese Lücke. Im WYSIWYG-Modus erscheint ein Verweis jetzt als hochgestellte Ziffer und eine Definition als umrandeter Block an der Stelle, an der sie im Quelltext steht.

Eine neue Fußnote entsteht über den Eintrag „Footnote“ im Slash-Menü, über einen Knopf in der Werkzeugleiste oder mit ⌘⇧F, unter Windows und Linux Strg+Umschalt+F. Der Verweis bekommt die nächste freie Nummer, am Seitenende entsteht eine leere Definition, und der Cursor steht darin. Ein Klick auf den Verweis springt zur Definition, ein Klick auf deren Nummer zurück zum ersten Verweis.

Ganz fertig ist der Editor damit nicht. Wort-Labels wie [^reboot] lassen sich im WYSIWYG-Modus nicht umbenennen, dafür bleibt der Markdown-Modus. Wer einen Verweis löscht, behält dessen Definition im Text, und Definitionen ohne Verweis erscheinen nicht auf der Seite.

Für bestehende Installationen gilt bei allen fünf Releases dasselbe. Es gibt keine inkompatiblen Änderungen an API, MCP-Werkzeugen, Seitenformat oder Konfiguration. Nur das Standardaussehen ohne Theme hat sich mit 1.2.5 und 1.2.6 geändert, und use: rotecodefraktion stellt das alte wieder her.

Ausprobieren lässt sich alles in der Live-Demo. Die Vorlagen wechseln Nutzer unter „Einstellungen, Erscheinungsbild“ für sich selbst, ohne andere zu beeinflussen.

Quellen