Oder warum hier jetzt gar kein Highlighter mehr läuft.
Hier war bis vor kurzem eine alte Version von Highlight.js eingebunden. Die machte einen ganz ordentlichen Job, die diversen Codeblöcke in diesem Blog aufzuhübschen, Codeelemente in verschiedenen Sprachen einzufärben. Aber es schlichen sich da auch immer wieder Fehler ein, vor allem bei modernen Konstruktionen, die das alte Skript nicht kennen konnte. Also machte ich mich auf der Suche nach einem Update. Daraus wurde die Suche nach einer Alternative. Und weil das frustrierend war, packe ich die Suchergebnisse wenigstens hier in den Blog.
Kurz zu meinen Anforderungen: Meine Codeblöcke sind in <pre class="code"> verpackt. Welche Sprache da drin ist soll automatisch erkannt werden, wennn das gelegentlich mal schiefgeht ist das okay, optional die Sprache festsetzen zu können wäre nett (habe ich aber noch nie gemacht). Der Codeblock soll danach gut aussehen, Dunkelmodusunterstützung inklusive, habe ich das doch gerade erst in meine Version von highlight.js reingehackt gehabt. Unterstützt werden soll PHP, Ruby, Dart, Bash, Javascript, INI- und sonstige Konfigdateien, JSON, HTML, CSS und eigentlich auch Kotlin und Java. Im Idealfall gibt es ein Fallback für C-artige Sprachen. Aktives Projekt wäre gut, die Sprachen entwickeln sich ja weiter.
Und es soll Javascript sein, damit ich es einfach in den Blog einbauen kann ohne all die alten Artikel anpassen zu müssen.
Eine aktuelle Version von Highlight.js wäre natürlich meine erste Wahl gewesen. Das lief jetzt ewig hier im Blog, kann Programmiersprachen automatisch erkennen und es ist immer noch ein aktives Projekt.
Aber es ist mittlerweile unnutzbar fett geworden. Das Projekt unterstützt jetzt wesentlich mehr Sprachen als vorher, aber auch wenn man die im Konfigurator nicht alle aktiviert, sondern sich auf das "Common"-Set beschränkt, ist die minifizierte Datei dann 156KB groß. Da sind ein paar Sprachen dabei, die ich sicher nicht brauchen werde und daher raus können – wie GraphQL oder Objective-C – danach sind es immer noch 132 KB. Das ist wahnsinnig viel. Vor allem für ein Feature, das bei weitem nicht alle meine Artikel brauchen. Highlight.js ist damit raus.
Prism wäre die große Alternative. Das Projekt wirbt damit, wie leichtgewichtig es ist. Und dann gibt es auch noch ein Autoloader-Plugin, sodass immer nur die benötigte Sprachendefinition geladen werden müsste.
Aber Prism ist völlig unbrauchbar, denn es wolle gute Codequalität erzwingen bzw was sie dafür halten. Das listen sie glatt als Feature:
Encourages good author practices. Other highlighters encourage or even force you to use elements that are semantically wrong, like <pre> (on its own) or <script>. Prism forces you to use the correct element for marking up code: <code>. On its own for inline code, or inside a <pre> for blocks of code. In addition, the language is defined through the way recommended in the HTML5 draft: through a language-xxxx class.
Schon damit ist Prism raus – hier im Blog wird Code seit 15 Jahren eben nur mit einem Pre-Element markiert und das werde ich sicher nicht grundlos ändern. Außerdem scheint Prism Codesprachen auch nicht automatisch erkennen zu können, zumindest wird das nirgends erwähnt.
Wenn Prism die große Alternative war, ist Shiki wohl die moderne.
Sie ist leider genauso unbrauchbar wie Highlight.js. Fokus ist auf der Ausführbarkeit mit Node, zu Browsern heißt es hier:
It's quite efficient as it will only load the languages and themes on demand. For the code snippet above, only four requests will be fired (shiki, shiki/themes/vitesse-light.mjs, shiki/langs/javascript.mjs, shiki/wasm.mjs), with around 200KB data transferred in total.
Da kann das Ergebnis noch so genau sein, das ist absurd groß. Das auch noch für effizient zu halten ist völlig disqualifizierend.
Rainbow fand ich vielversprechend, denn es sei klein und bei den unterstützten Sprachen wird immerhin Shell, Ruby und PHP gelistet, mein Minimum. Und ein Fallback (generic) scheint es auch zu geben.
Aber Rainbow hat mehrere Probleme. Das erste, dass das Projekt seit 4 Jahren kein Update mehr sah. Das zweite, dass der Beispielcodeblock auf der Projektseite unnangenehm lange einfach schwarz bleibt. Drittens ist in der Dokumentation plötzlich die Rede davon, alle Sprachen manuell einbinden zu müssen, was in einem Blog so gar nicht passt. Und schließlich ist von automatischer Sprachenerkennung auch keine Rede, wobei ein entsprechendes Issue 2017 als erledigt geschlossen wurde.
Das wirkt im momentanen Zustand nicht benutzbar, das müsste erstmal entstaubt werden.
Als ich schließlich über Speed-highlight JS stolperte dachte ich, die perfekte Lösung sei zum Greifen nahe. Das Projekt präsentiert sich als Alternative zu Prism, ohne auf <pre><code> zu bestehen – stattdessen wird ein div gefordert, aber dann geht bestimmt auch ein <pre>.
In der Dokumentation wird eine automatische Sprachenerkennung beschrieben (optional, aber eben da), die Downloads auf der Demoseite sind angemessen klein, das Ergebnis sieht gut aus. Sogar aktiv ist das Projekt noch, letzten Monat gab es einen Commit. Es wirkt wie ein gut gebautes, vernünftiges Projekt, dem nur etwas Dokumentation fehlt um die Installation zu erklären, was man aber rauskriegen könnte…
…und dann ist weder Ruby noch PHP in der Liste der unterstützten Sprachen, auch Dart fehlt. Hmpf.
Die ergebnislose Suche nach einer Javascriptlösung hat mich dann dazu gebracht, mit CSS-Designs für die Codeblöcke hier im Blog zu spielen. Dass die generell besser aussahen war damals ein großer Pluspunkt von Highlight.js gewesen, entsprechend ginge da vielleicht auch eine Lösung ohne Syntaxhighlighting. Darüber landete ich letzten Endes bei der minimalen Lösung, die Codeblöcke ohne Rahmen einfach mit etwas Leerraum drumrum in Monospace zu setzen. Ich finde, das sieht erstmal gut genug aus.
Gleichzeitig habe ich die Releases von Speed-Highlight in meinen Feedreader gepackt. Für 1.3.0 wäre sowohl Ruby als auch PHP geplant. Leider ist das Issue schon seit 2022 auf, aber es kann ja trotzdem noch kommen.
Über zwei alternative Ansätze bin ich auch noch gestolpert, mit denen sich die JS-Highlighter vielleicht bald ersetzen lassen oder womit sie sich ändern könnten. Einmal die geniale Idee, das farbliche Markieren in die Schriftart einzubauen. Dann bräuchte es keine Javascriptlösung mehr. Zweitens gibt es eine recht neue CSS-API zum Hervorheben von Textabschnitten, mit der die JS-Highligher bald arbeiten könnten.
So unbefriedigend der derzeitige Zustand der Projekte für einen Blog wie diesen auch sein mag, ist da also doch die Aussicht auf eine Verbesserung.
Warum muss das Highlighting denn auf dem Client laufen?
Du könntest vorformatierten Code einbetten oder z.B. Geshi als s9y-Plugin nutzen (keine Ahnung, wie da die Sprachabdeckung ist, bei mir hat's gepasst).
Geht aber beides so ohne weiteres nicht für existierende Artikel.
Genau:
> Geht aber beides so ohne weiteres nicht für existierende Artikel.
Ich wollte immer eine einfache Lösung, die mit dem bestehenden HTML zurechtkommt. Und dann ja auch entsprechend auswechselbar wäre, anders, als wenn ich jetzt Geshi oder eine andere Serverlösung einbauen würde. So kam ich da übrigens drauf, erinnere ich mich gerade, dieser Artikel über eine alternative Serverlösung namens Tempest. Daher waren die JS-Lösungen für mich immer attraktiv und eigentlich gesetzt, auch weil der Code ja auch ohne das Highlighting noch lesbar ist, JS hier also prinzipiell keine Nachteile hat.
Stimmt natürlich, dass die Auswechselbarkeit nicht viel bringt wenn es keine brauchbaren Alternativen gibt...
onli blogging am : Designänderungen im Blog: Artikelüberschriften, Hintergrund, Textumbrechung
Vorschau anzeigen