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.
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.
Man bindet „einfach“ ein script-Element mit dem XHTML-Namespace in die XML-Datei ein. Das führt der Browser dann aus.
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.
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.
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:
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
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!
Ich habe in den letzten Monaten eine Menge über Web Intents gelesen und ich finde immer noch dass der Webmonkey die Thematik bisher am treffendsten beschrieben hat:
In practice Web Intents work a bit like mailto: links, defining an action and then passing it along to the browser, which allows the user to choose how to handle the action. The difference is that instead of opening a desktop app, Web Intents connect to web services.
Der Vergleich ist simple und ich habe mir die Frage gestellt: Wieso nicht einfach wirklich unterschiedliche Schemes für die jeweiligen Anforderungen definieren? Eine App kann beim Browser anmelden dass sie share:// oder subscribe:// unterstützt und bei einem Klick auf einen entsprechenden Link, öffnet sich (statt der E-Mail App) eben die entsprechende Web-App.
…vor kurzem hab ich dann mal ein wenig mit Superfeedrsmsgboy herumgespielt und entdeckt dass es bei HTML5 wirklich Custom-Schemes gibt die man frei definieren kann!
Mit folgendem Befehl kann man beim Browser einen eigenen Protocol-Handler setzen:
Bisher war ich ja ein großer Web Intents Fan (und bin es auch immer noch), aber für solche simplen Aktionen wie "Share", "Like", "Subscribe" oder "Follow" reicht doch ein simples Custom-Scheme vollkommen aus. Kein unnötiges JavaScript (mal abgesehen vom Registrieren des Handlers), nur ein wenig HTML. Großartig!
Protocol-Handler lassen sich übrigens auch abhängig vom Mime-Type setzen:
Da findet man ein paar echt schicke Sachen im Web und nimmt sich vor mal darüber zu bloggen… richtig drüber zu bloggen… nicht als OpenWeb-Notizen oder solches Zusammenfass-Zeugs… richtig drüber bloggen! …und dann vergisst man ’s oder hat keine Zeit!
Also hier ein paar echt großartige Microformats-News… Zusammengefasst!
Und schon wieder Glenn Jones, diesmal mit einem Microformats/HTML5/JavaScript/Drag&Drop – Dingens. Mit dem Script ist es möglich, Microformats zwischen unterschiedlichen Seiten per drag&drop auszutauschen:
Having observed users connect to sites using OAuth without really understanding what exchange of data has taken place, I decided to investigate other metaphors/conventions that might be more transparent. Draggables is a series of demos that explore the use of drag and drop to directly exchange data between web sites.
Das ist nicht ganz neu, aber gar keine schlechte Idee… ein Profil mit der Maus auf das Adressbuch zu ziehen ist sicherlich verständlicher als die ganze OAuth oder OpenID Hin-und-Her-Leiterei… zumindest für Web-Neulinge!
hForms
…und nochmal Glenn Jones. Zu guter Letzt treibt er noch das hcard-input-brainstorming voran um auch Profil- oder Event-Eingaben zu standardisieren… hForms oder Microforms so zu sagen 🙂
Use hCard properties as class names on form elements inside a container (such as a containing <fieldset> or the containing <form>) to indicate that those form elements accept values with the semantics of the respective hCard properties.
So, genug für heute! Demnächst gibt’s dann auch noch ein bisschen mehr zu OStatus for WordPress… natürlich ausführlich und nicht zusammengefasst 🙂
Jetpack ist das jüngste Baby der Mozilla Labs und bietet eine Art API, die es Entwicklern ermöglicht, den Firefox mit klassischen Web-Techniken (HTML, JavaScript und CSS) zu erweitern. Statt mit XUL kann man seine Firefox Addons demnächst vielleicht wirklich mit HTML und CSS gestalten. Großartige Idee!
Übrigens unterstützt Jetpack, wie auch Ubiquity, die ab der Version 3 in Firefox nativ implementierte Microformats API. Der folgende Code zeigt, wie man die Microformats API in Jetpack-Skripte integrieren kann. Das Beispiel zählt z.B. alle hCards der Seite, auf der man sich gerade befindet und zeigt das Ergebnis per Info-Message an:
Components.utils.import("resource://gre/modules/Microformats.js");
// count hCards
jetpack.tabs.onFocus(function() {
// load HTMLvar doc = jetpack.tabs.focused.contentDocument;
// count microformats var uFcount = Microformats.count('hCard', doc);
// load notifier
jetpack.notifications.show({
title: 'hCards',
body: 'number of hCards on this website: ' + uFcount,
icon: 'http://microformats.org/favicon.ico'
});
});Code-Sprache:JavaScript(javascript)
Nachtrag:
Unter Windows und Linux scheinen die Messages nicht so ganz zu funktionieren, deshalb gibt’s hier nochmal nen Beispiel wo der Counter in der Statusbar ausgegeben wird:
Wie in meinem letzten Post über den hCardMapper beschrieben, war es in der Tat nicht möglich den Microformats-Parser/Proxy ohne weitere Probleme auszutauschen. Die generierten JSON Formate der einzelnen Parser (ufXtract, hKit, mofo) unterscheiden sich an einigen Stellen zu sehr um sie alle gleich behandeln zu können. Soweit zur schlechten Nachricht…
Die gute Nachricht ist, dass sich Gordon Oheim (der Macher des hCardMappers) nochmal alle JSON Formate vorgenommen und eine neue Version gebastelt hat:
v0.94 – Added better support for JSON returned by Optimus, ufXtract and hKit.
Der Mapper sollte also mit mofo, Optimus, ufXtract and hKit problemlos funktionieren.
Die nächste tolle Nachricht ist, dass Gordon auch auf einen kleinen Änderungswunsch von mir sofort eingegangen ist, so dass wir euch jetzt eine hCardMapper Edition von dem WordPress hCard-Commenting Plugin anbieten können :).
Wenn ihr immer die aktuelle Version haben wollt, hier ist der Link zum SVN.
Ich hab das Plugin auch mal auf notizBlog aktiviert und würde mich über euer Feedback freuen. Macht es Sinn über das Admin-Menü zwischen beiden Versionen (hCard-Commenting und hCardMapper-Commenting) zu wechseln?
Ein dickes Danke nochmal an Gordon für seine tolle und schnelle Arbeit… tolles Script.
hCardMapper ist eine JavaScript-Klasse (basierend auf Prototype) um Kontakt- oder Profil-Formulare mit Hilfe einer hCard automatisch zu füllen, ähnlich wie bei bragster.com oder getsatisfaction.com.
Das schöne an hCardMapper ist seine flexible Struktur. Die JavaScript Klasse ist so aufgebaut, dass sie eigentlich Microformats-Parser unabhängig funktionieren sollte, da sie die Daten über einen „Proxy“ abfrägt. Die einzige Vorgabe ist, dass dieser Proxy eine JSON formatierte hCard (jCard) zurückgibt. Das Problematische an dieser Variante ist, dass jeder Parser unterschiedliche Ergebnisse liefert… ich werde es heute abend mal mit dem hKit-Parser testen.
Ein weiter Vorteil ist die Formular-Unabhängige Programmierung die es ermöglicht, das Script auch problemlos auf vorhandene Formulare anzuwenden. Über mappnings werden die hCard-Attribute den entsprechenden Formular-Felder zugeordnet.
I wrote a small User Script for the Operator Toolbar (Firefox Plugin to handle Microformats), so you can transform the detected microformats using the Optimus transformer. Optimus supports two kinds of transformations (microformats to jSON or to XML) and a basic microformats validation.
microJSON ist ein Projekt von Jon Sykes und Jim Barraud. Es geht darum, Microformats in Form der JSON Schreibweise darzustellen. Die Idee von JSON ist, einen einfachen Datenaustausch von Objekten oder auch anderen Datenstrukturen wie z.B. Arrays zwischen Client Systemen (z.B. dem WebBrowser) und Server Systemen zu realisieren. Der Vorteil von JSON ist, dass sie kaum Overhead produziert und in JavaScript über die eval() Funktion wieder ganz einfach in ein Objekt gewandelt werden kann.
Neben den Abbildungen der Microformats hCard (jCard) und hCalendar (jCalendar) sind auch die Format jAtom, jResume, jReview, jAtom und jResume geplant. Weitere abbildung gibt es für normale Formulare (jForm), sowie auch für RSS Feeds (jRSS).
MicroJSON sind meiner Meinung nach eine sehr gute Idee, wenn man Bedenkt dass viele gute Microformats Parser, wie z.B. der vom Firefox Addon Operator verwendete ufParser, auf JavaScript basiert.
Stephan Gerbeth hat auf seiner Webseite „scheinwohnsitz.de“ eine wirklich tolle Idee für eine Navigation gehabt. Die ganze Seite lässt sich komplett über das kleine Häuschen steuern (JavaScript/Ajax).
