Vor etwas über einem Jahr habe ich meinen Blog gestartet. Zugegeben, allzu viel ist seitdem nicht passiert. Das liegt weniger daran, dass es nichts zu berichten gäbe, als viel mehr an meiner knappen Zeit. Es gibt allerdings noch viele Dinge, zu denen ich hier kleine Tutorials schreiben möchte (zum einen für die Leser, zum anderen aber auch für mich als Gedächtnisstütze), doch zuvor musste etwas an meinem Blog selbst erledigt werden.
Warum XML?
Wie man (hoffentlich nicht allzu sehr) merken konnte, hatte ich die vorige Version meines Blogs mit XML und XSLT realisiert. Doch warum das ganze? Ich kam im ersten Semester meines Informatikstudiums zum ersten Mal mit XSLT in Kontakt. Obwohl ich XML schon lange kannte, offenbarte dieser neue Ansatz einige interessante Möglichkeiten, insbesondere, da ich immer auf der Suche nach möglich minimalen Lösungen für meine Probleme bin.
Jekyll kannte ich zu dieser Zeit noch nicht und dynamische Blogs mit PHP und Konsorten kamen für meine kleinen Vorhaben nicht in Frage. Also entschloss ich mich, meine Blogposts als XML-Dateien zu verfassen und diese dann mit XSLT durch den Browser in HTML umformen zu lassen. Bis hierhin auch durchaus ein machbarer Plan, der zu guten und sauberen Ergebnissen führt. Die Postings bilden eine Textdatenbank, die mit .dtds validiert werden kann, mit etwas penibler Arbeit sieht das erzeugte HTML aus wie von Hand geschrieben und wenn noch CSS ins Spiel kommt, sind Inhalt, Markup und Style wirklich so perfekt voneinander getrennt, wie man sich das nur wünschen kann. Doch wehe man will mehr!
Probleme
Die ersten Probleme traten auf, als ich die Seite mit Chrome unter Android getestet habe. Scheinbar zufällig schien der Browser (zumindest in der damals aktuellen Version) sich nicht mehr sicher zu sein, ob er für das Öffnen von .xml-Dateien auch wirklich zuständig ist, und zeigte den Android-typischen ‘Öffnen mit’-Dialog. Wenn das auch nur ein kleineres Problem ist, macht es auf einen eventuellen Besucher doch einen recht zwilichtigen Eindruck. Mit Firefox auf Android oder Desktop-Browsern habe ich dieses Problem im Übrigen nie erlebt.
Wirklich interessant wird es aber erst, wenn man es wagt, XML und XSLT in Verbindung mit SEO und Social-Media zu bringen. Es ist völlig unergründlich, nach welchen Kriterien Google & Co. entscheiden, welche Meta-Informationen einer Webseite sie aus XML, XSLT oder dem generierten HTML ziehen. So fängt man an, die eigentlich schöne Trennung von Inhalt und Markup Stück für Stück aufzugeben und da sich selbst die Tools eines Herstellers teilweise unterschiedlich verhalten, müssen manche Informationen so gar doppelt angegeben werden:
Alle OpenGraph-Elemente für Facebook müssen in die XML-Datei, ebenso die schema.org Informationen für Google.
icon, apple-touch-icon und die Icons für Windows-Live-Kacheln müssen sowohl in die XML- als auch in die XSLT-Datei, da sich die Browser nicht so ganz einig sind, woher sie diese Information beziehen.
Hat man diese beiden Klippen umschifft, ist aber noch nicht alles in trockenen Tüchern, da Facebook seine Snippets für die Darstellung in der Timeline aus dem XML ausliest und Google meistens (!) auch. Also müssen die in der selbst erstellten DTD definierten XML-Tags die gleichen Namen tragen wie die entsprechenden HTML-Tags. Man hat nun also HTML-Tags in einer XML-Datei, die mit einer XSLT-Datei (die HTML enthält) zu einer HTML-Datei umgewandelt wird. Eine wirkliche Trennung findet nun eigentlich schon nicht mehr statt. Als kleines Beispiel hier mal mein MenuLibre-Post als XML:
Auffällig ist vor allem, wie klein nur der Anteil des eigentlichen Texts ist (auch wenn es zugegebenermaßen ein kurzer Post ist). Auch hässliche Krücken wie <![CDATA[…]]> muss man immer wieder bemühen. Schaut man sich außerdem nur den Textteil an, sieht man eigentlich schon reines HTML. Trotzdem hier noch das passende XSLT:
Wie man sieht, ist diese Methode also alles in allem wenig effizient und meiner eigentlichen Suche nach einer möglichst minimalen Lösung wohl kaum gerecht.
Vorteile?
Kaum.
Aber trotzdem habe ich das Verfahren zu schätzen gelernt. Es nutzt offene, altbewährte und gut unterstützte Standards und man hat jederzeit volle Kontrolle über das was passiert. Es gibt keine Blackbox, keine Magie (@Autowired bei Spring hust) und nur ein leicht zu überschauendes Set an Möglichkeiten. Und für spezielle Einsatzmöglichkeiten reicht das auch vollkommen aus. So habe ich beruflich bereits einen in XML vorliegenden Bibliotheksbestand in eine einfache, durchsuchbare und übersichtliche Webseite umgewandelt, ohne dass bei jeder Änderung am Bestand auch die Seite geändert werden müsste. Für genau solche Szenarien eignet sich XSLT auch heute noch sehr gut, für die von mir gedachte Realisierung eines Blogs rückwirkend betrachtet weniger.
Jekyll
Genau deswegen habe ich jetzt (solange ich noch so wenige Posts habe) meinen Blog auf Jekyll umgestellt und ich muss sagen, es gefällt mir sehr gut. Auch wenn mir als nicht Ruby-Nutzer die Einarbeitung in die Gems (Builder, Bundler, Gems?) und das Installieren von Plugins ein paar Kopfschmerzen bereitet haben, fällt die Bedienung insgesamt doch recht einfach aus und auch das Standard-Theme ist durchaus als Grundlage brauchbar.
Im Gegenzug habe ich mir mit Jekyll eine Blackbox eingefangen, die allerdings so gut und einfach zu bedienen ist, dass ich diesmal damit Leben werde.