Monat: Oktober 2026

  • ,

    Ich hab in den letzten Wochen ziemlich viel an meinen Slashpages rumgebastelt. Ich liebe die Idee! Slashpages helfen dabei, ein Blog, seinen Hintergrund und die Person dahinter ein bisschen besser zu verstehen (frei nach @ix).

    Im Prinzip ist die Idee super simpel: einfach /about eingeben und man landet auf dem Profil. Um zu sehen, welche Slashpages ein Blog hat, müsste man aber alle einzeln überprüfen.

    Deshalb hab ich mir /.well-known/slashpages überlegt, eine einfache Liste mit allen Slashpages eines Blogs. Eine well-known Seite für well-known Seiten… irgendwie ironisch, aber bei knapp 80 Seiten sind das halt ’ne ganze Menge Links 😉

    Inspiriert ist das Ganze von .well-known/feeds und /.well-known/recommendations.opml .

    Die Spec

    Die Spec beschreibt, wie die Liste aussieht. Es ist eine OPML-Datei, in der jede Slashpage ein outline ist. Der Titel steht in text, der Name der Slashpage in category und die Adresse in url:

    <outline
	type="link"
	text="Was ich gerade mache"
	category="/now"
	url="https://notiz.blog/now/"
/>Code-Sprache: HTML, XML (xml)

    Die URL soll der bekannte Pfad sein, also z.B. /now/. Liegt die Seite woanders, darf die URL auch dorthin zeigen.

    Hat eine Seite mehrere Namen, stehen alle in category, z.B. category="/changelog,/log". Man kann auch weitere OPML-Dateien einbinden, und die Datei sollte mit Access-Control-Allow-Origin: * ausgeliefert werden, damit auch Tools im Browser sie lesen können.

    Die /slashes-Seite ersetzt das übrigens nicht. /slashes ist für Menschen, /.well-known/slashpages für Maschinen.

    Das WordPress-Plugin

    Das Plugin stellt die Datei unter /.well-known/slashpages (und /.well-known/slashpages.opml) bereit.

    Unter Einstellungen → Slash Pages stehen alle Slashpages von slashpages.net. Für jede kann man eine Seite auswählen, eine eigene URL eintragen (z.B. für Seiten, die nicht in WordPress liegen) oder sie einfach leer lassen. Gibt es schon eine Seite mit passendem Slug, z.B. now, ist sie schon ausgewählt.

    WordPress-Einstellungen „Slash Pages“ mit Seitenauswahl und URL-Feld für jeden Pfad. /about, /blank und /blogroll sind zugeordnet, /ai ist noch leer.

    Die OPML kann man sich auch im Browser anschauen. Dafür bringt das Plugin ein kleines Script mit, genau wie bei .well-known/feeds, nur ohne XSLT.

    Browseransicht von /.well-known/slashpages auf notiz.blog mit einer Erklärung zu OPML und verlinkten Slashpages wie „About (me)“, „Blank“ und „Blog·rol·le, die“.

    Die Browser-Erweiterung

    Die Erweiterung prüft auf jeder Seite einmal, ob es eine /.well-known/slashpages gibt. Wenn ja, wird das Icon blau und zeigt die Anzahl der Slashpages. Wenn nicht, bleibt es grau. Ein Klick auf das Icon listet die Seiten mit ihren Namen auf.

    Geöffnete Slashpages-Erweiterung auf notiz.blog. Das blaue Icon zeigt 11, die Liste enthält Seitentitel und Pfade, darunter /changelog und /log für denselben Eintrag.

    Hat eine Seite keine /.well-known/slashpages, probiert die Erweiterung beim Klick die bekannten Pfade von slashpages.net einzeln durch. Das sind rund 80 Requests, deshalb passiert das nur, wenn man klickt.

    Slashpages-Erweiterung auf simon.blog mit dem Hinweis, dass keine /.well-known/slashpages vorhanden ist. Über die Pfadsuche wurden /about, /blogroll, /follow und /now gefunden.

    Für die automatische Prüfung braucht die Erweiterung Zugriff auf alle Seiten. Den kann man im Browser auch abschalten, dann funktioniert nur noch der Klick. Daten sammelt die Erweiterung keine.

    Sie läuft in Firefox, Chrome (und Edge, Brave, …) und Safari.

    Plugin und Erweiterung gibt es bisher nur auf GitHub. Falls ihr Feedback habt, ich würde mich sehr über eure Ideen freuen!

    Ich glaube, das ist ein bisschen ausgeartet… 🫣

    13 Kommentare 10 Reposts 15 Likes 1 Lesezeichen

  • Vor ein paar Tagen habe ich mich noch darüber aufgeregt, dass Browser künftig wohl kein XSLT mehr unterstützen werden. Es mag sein, dass ich da vielleicht etwas zu hysterisch voreilig war.

    @krinkle hat mich in den Kommentaren auf einen Blogpost und einen Pull Request hingewiesen, die zeigen wie man mit JavaScript zu einem ähnlichen Resultat kommt. (Danke nochmal dafür!)

    If you just want to make some existing XSLT work in browsers that don’t support it, check out Mason’s XSLT polyfill. But if you don’t need to use XSLT, JavaScript is, in my opinion, a better option.

    Making XML human-readable without XSLT

    Statt JavaScript zu verwenden, um XSLT über WebAssembly clientseitig auszuführen, könnte man JavaScript auch direkt nutzen, um das XML zu transformieren.

    Hätte man auch gleich drauf kommen können!

    Ich hab mir also mal einen Abend Zeit genommen und das OPML für das SocialSpec Plugin (mehr dazu bald) von XSLT auf JavaScript umgezogen.

    Screenshot einer gestalteten OPML-Liste „notizBlog Follows“ auf notiz.blog: Ein Hinweiskasten erklärt OPML, darunter stehen abonnierte Blogs mit Beschreibung, Feed-URL und je einem „Subscribe“-Button.

    Man bindet „einfach“ ein script-Element mit dem XHTML-Namespace in die XML-Datei ein. Das führt der Browser dann aus.

    <opml version="2.0">
  <script xmlns="http://www.w3.org/1999/xhtml" src="opml.js" defer=""/>
  <head>…</head>
  <body>…</body>
</opml>Code-Sprache: HTML, XML (xml)

    Das Script liest die Daten aus dem OPML, baut daraus eine HTML-Seite und ersetzt damit das XML (document.documentElement.replaceWith( html )). Feed-Reader ignorieren das Script und bekommen weiter das normale OPML.

    Ich arbeite jetzt seit fast zwei Jahrzehnten mit offenen Formaten und Web Standards und bin bei der Technik inzwischen ziemlich leidenschaftslos. Ich finde XSLT zwar immer noch charmanter, aber das hilft ja nicht, wenn kein Browser es unterstützt.

    So lange das Ergebnis das gleiche ist, ist mehr der Weg dahin mittlerweile fast egal.

    XSLT ist tot, lang lebe JavaScript!

    8 Kommentare 9 Reposts 12 Likes 3 Erwähnungen

  • Ich habe bei Dave Winer gelesen, dass XSLT aus den Browsern entfernt werden soll.

    Ich habe gerade alle XML Formate die ich in WordPress finden konnte, mit XSLT aufgehübscht und jetzt beschließen Google & Co. ernsthaft den Support einzustellen!?!?

    Aber bevor ich weiter „rante“, hier ein kurzer Einschub was XSLT überhaupt ist: Mit XSLT lassen sich XML-Dateien in andere Formate umwandeln, zum Beispiel HTML. Man verlinkt dazu ein Stylesheet in der XML-Datei und der Browser übernimmt die Umwandlung. So wird aus einem RSS-Feed eine lesbare Webseite. Ohne JavaScript und ohne dass man dafür auf dem Server etwas installieren muss.

    Für den Feed-Reader ändert sich dabei nichts. Der bekommt weiterhin die XML-Datei. Wenn ihr den Feed im Browser öffnet, seht ihr dagegen Beiträge, Links und eine Erklärung wie ihr ihn abonnieren könnt.

    Ich benutze das hier seit einer ganzen Weile. 2020 hab ich meinen RSS-Feed mit XSLT und CSS gestaltet. Später kam die OPML-Ausgabe meines .well-known/feeds Plugins dazu. Und jetzt auch die OPML-Dateien meiner Blogroll.

    Screenshot des RSS-Feeds von notiz.blog im Browser, mit XSLT als lesbare Webseite dargestellt. Oben erklärt ein gelber Bereich mit RSS-Symbol, wie man den Feed abonniert. Darunter stehen das Blog-Logo, die Beschreibung und die neuesten Beiträge als anklickbare Links.

    Bei OPML finde ich das besonders praktisch: Ihr klickt auf den Link und bekommt eine Liste von Blogs durch die ihr stöbern könnt. Die gleiche URL könnt ihr in euren Feed-Reader importieren. Man muss nicht einmal wissen was OPML ist um etwas damit anfangen zu können.

    @ix hat auch gerade nochmal über seine Basteleien geschrieben. Er hübscht seine OPML-Dateien auch mit XSLT auf und inzwischen auch seine RSS-Feeds.

    Die generelle Idee hinter XSLT erinnert mich sehr an den Microformats-Grundsatz:

    Designed for humans first and machines second

    microformats.org

    Bei Microformats ergänzt man das HTML einer Webseite so, dass auch Software etwas damit anfangen kann. Das gleiche HTML für Menschen und Maschinen. Bestehendes sinnvoll erweitern, mit dem arbeiten was schon da ist.

    XSLT macht im Prinzip das Gleiche, nur aus der anderen Richtung:

    Designed for machines first and humans second

    Die XML-Dateien bleiben für Maschinen lesbar. Mit einem Stylesheet können aber auch Menschen etwas damit anfangen.

    RSS und OPML sind ein wesentlicher Bestandteil des Open Webs. Wir verlinken sie an so vielen Stellen, weil wir wollen dass Besucher es einfach haben den Blog zu abonnieren oder weil wir ihnen neue Links vorschlagen wollen. Was sie in Zukunft sehen werden ist reines XML. Keine Möglichkeit irgendetwas zu erklären oder auf das Wesentliche aufmerksam zu machen! Nur XML!

    Leider ist das auch keine rein theoretische Diskussion mehr. Stand 5. Oktober 2026:

    • Chrome: XSLT ist bereits deprecated. Die Abschaltung ist für Chrome 158 am 17. November 2026 geplant. Befristete Ausnahmen für registrierte Websites und verwaltete Browser sollen am 17. August 2027 enden. Betroffen sind sowohl die Verknüpfung mit einem XSLT-Stylesheet als auch die JavaScript-API XSLTProcessor. Zeitplan von Chrome
    • Firefox: Mozilla hat die Abschaltung für August 2027 angekündigt. Intent to Unship
    • Safari/WebKit: WebKit unterstützt die Entfernung grundsätzlich, formuliert seine Zustimmung aber vorsichtig. Einen verbindlichen Abschalttermin habe ich in den geprüften Quellen nicht gefunden. WebKits Stellungnahme

    Bei Chromium ist die Entfernung bereits beschlossen. Noch ist XSLT aber nicht aus allen Browsern verschwunden und auch die Änderung am HTML-Standard ist noch offen.

    RSS, Atom und OPML funktionieren natürlich weiter. Entfernt wird die XSLT-Verarbeitung im Browser. Der Reader kann meinen Feed also weiterhin lesen, aber wer auf den Link klickt bekommt die XML-Ansicht.

    Die Begründung der Browserentwickler sind Sicherheitslücken, Wartungsaufwand und geringe Nutzung. Das sind alles nachvollziehbare Argumente. Trotzdem finde ich den Verweis auf JavaScript und moderne Frameworks als Ersatz unbefriedigend. Ich hab eine XML-Datei und ein Stylesheet. Für das was ich damit machen will hat das bisher gereicht!

    Was können wir stattdessen machen?

    • XSLT mit JavaScript nachrüsten. Es gibt einen Polyfill mit WebAssembly, den man direkt in die XML-Datei einbindet. Der Browser führt damit das Stylesheet aus, der Reader bekommt weiterhin XML. Das könnte die bisherige Darstellung unter der gleichen URL erhalten. Allerdings dokumentiert das Projekt Unterschiede zur eingebauten XSLT-Verarbeitung, etwa beim Nachladen weiterer Dateien. Ob es mit meinen Stylesheets und den Readern funktioniert müsste ich ausprobieren.
    • XML mit CSS gestalten. Das bleibt möglich. Die gleiche XML-Datei lässt sich damit im Browser lesbar darstellen, für Reader ändert sich nichts. CSS kann aber nicht alles was XSLT kann: Aus einer URL in einer OPML-Datei wird dadurch noch kein anklickbarer HTML-Link. Für eine einfache Ansicht kann es trotzdem reichen.
    • HTML und XML unter der gleichen URL ausliefern. Mit Content Negotiation könnte der Server anhand des Accept-Headers entscheiden welche Version er zurückgibt. Nur für die HTML-Version würde ich XSLT auf dem Server ausführen, Reader müssten weiterhin das ursprüngliche XML bekommen. Eine zusätzliche öffentliche URL braucht es dafür nicht. Der Haken: Browser und Reader lassen sich über den Header nicht zuverlässig auseinanderhalten. Das müsste ich mit verschiedenen Readern testen. Caches brauchen außerdem Vary: Accept damit sie die Versionen nicht verwechseln.

    Ganz ehrlich? Das ist alles 💩 und keine wirkliche Alternative!

    Gewöhnt euch lieber schon mal wieder an XML!

    8 Kommentare 14 Reposts 18 Likes 1 Zitat 1 Lesezeichen 2 Erwähnungen