RSS Rich Site Summary (originally RDF Site Summary, often dubbed Really Simple Syndication) is a family of web feed formats used to publish frequently updated works—such as blog entries, news headlines, audio, and video—in a standardized format.
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!
Und jetzt bin ich aktives und zahlendes Mitglied bei Rivva und beteilige mich am Starter-Packs Projekt!
Ich bin da wohl aus Versehen in was Großartiges reingerutscht 😉
Das Plugin selbst stellt eigentlich nur einen Block bereit. Man kann eine Blogroll in jeden Beitrag oder auf jede Seite packen, auch mehrmals, wenn man z.B. Blogs und Podcasts trennen will. Oder man verteilt die Blogrolls auf mehrere Seiten. Jede Blogroll hat dabei ihre eigene OPML.
Beim Hinzufügen reicht die URL. Name, Beschreibung, Icon und Feed holt sich das Plugin selbst, man kann aber alles noch anpassen. Es gibt keine Settings, alle Änderungen nimmt man direkt im Block vor.
Das Plugin gibt es auf WordPress.org und GitHub. Ich freue mich über Feedback, Ideen und Pull Requests!
(Das Plugin hieß ursprünglich übrigens „Blockroll“. Ein schlechtes Wortspiel: ein Gutenberg-Block, der eine Blogroll ausgibt. Nachdem in der Rivva-Community die Frage aufkam, was das Ganze mit Blocken zu tun hat, heißt es auf WordPress.org jetzt „Blogroll & Podroll Block“. Den Slug blockroll hab ich aber behalten, das Wortspiel konnte ich mir nicht verkneifen 😉)
((@simon bastelt außerdem schon an einem Logo für das Plugin (bzw. er lässt basteln)… mehr dazu bald))
Off the top of my head, it’s not the ability to syndicate, RSS already does that. I can follow anyone on any server.
Es macht natürlich Sinn, erstmal zu klären was RSS ist und kann, um auf die Vorteile von ActivityPub einzugehen!
Also RSS steht für „Really Simple Syndication“ und ist eine Art „Digitale Einbahnstraße“, so zu sagen der Newsletter oder Podcast für Texte auf Webseiten. Und weil es dem Podcast so ähnlich ist (und eigentlich auch dessen technische Basis) nennt es Dave Winer auch neuerdings „Textcasting„, was ich großartig finde!
Applying the philosophy of podcasting to text.
Und technisch gesehen ist das auch der große Unterschied zu ActivityPub. Während ich bei Textcasting, Texte nur abonnieren kann, habe ich durch ActivityPub auch einen Rückkanal, der mir ermöglicht, die Texte auch zu liken, mit meinen Freunden Followern zu teilen und zu kommentieren!
In den Kommentaren zu Daves Mastodon Post wird auch fast ausschließlich über diese technischen Aspekte diskutiert. Es geht um Push vs. Pull und immer wieder darum, dass RSS ja eigentlich vollkommen ausreichend und viel simpler ist.
I think RSS + Webmention (for sending replies) gets you 90% of the way there. ActivityPub does provide a comprehensive framework for the rest, though, and perhaps follows modern social network conventions more closely, e.g. liking posts, approving follows.
I saw the best minds of my time waste our time arguing about syndication formats, arguing about plumbing, user don’t care about plumbing but for some reason we thought that that mattered, we thought that actually really mattered which XML tags to use in RSS versus Atom. […] So we focused on the wrong things we argued about plumbing instead of user experience.
Vielleicht kommt man mit RSS, WebSub und Webmentions auf ein relativ ähnliches Ergebnis und es ist technisch gesehen wahrscheinlich auch etwas einfacher umzusetzen… Aber sind RSS und ActivityPub wirklich so weit auseinander?
Für mich ist ActivityPub einfach nur die logische Weiterentwicklung, oder auch die nächste Generation von RSS. Wer sich die erste Version von ActivityStreams (das Format, welches ActivityPub benutzt um Aktivitäten auszuzeichnen) etwas genauer ansieht, erkennt vielleicht ein alt bekanntes Format.
ActivityStreams wurden 2011 als Namespace für Atom definiert um RSS/Atom Feeds mit Informationen anzureichern, die man aus den sozialen Netzwerken kennt. Das ist hauptsächlich der object-type um neben Texten auch Bilder oder Videos auszuzeichnen, und verb um klar zu machen um was für eine Aktion es sich genau handelt.
Erst 6 Jahre später wurde die Version 2.0 als reines JSON Format veröffentlicht, was aber auch Sinn macht, da JSON das Format ist, welches moderne APIs eben sprechen.
Das heißt ActivityStreams ist im Prinzip eine moderne Form von RSS und ActivityPub ist einfach „nur“ ein PubSub System welches drumherum gebaut wurde.
Aber zurück zur Usability!
Die Frage ist für mich nicht RSS oder ActivityPub… Die wesentlich interessantere Frage ist: Feed-Reader oder Mastodon?
Die RSS oder IndieWeb Community (und ich zähle mich zu beiden, es geht hier nicht um Blaming) hat bisher leider kein massentaugliches Tool etabliert, welches mit der Usability und Reichweite von Mastodon (und Mastodon ist hier nur exemplarisch für eine Fediverse Platform… Pixelfed, Misskey und andere machen einen ähnlich guten Job) mithalten kann. Mastodon ermöglicht das dezentrale folgen, abonnieren, kommentieren, liken und sharen in einer simplen Oberfläche. Kein RSS-Reader, den man zum Kommentieren verlassen muss und kein IndieWeb-Reader, der eine eigene Webseite mit diversen Login- und Ping-Mechanismen voraussetzt!
Ich beschäftige mich jetzt seit ungefähr +/-15 Jahren mit dem Thema, welches man heute als Fediverse oder IndieWeb zusammen fassen würde, und habe auch ein gutes Jahrzehnt an Arbeit in diverse IndieWeb Projekte gesteckt, aber Mastodon und ActivityPub sind in ihren Auswirkungen bisher konkurrenzlos!
Dank Mastodon und ActivityPub habe ich wieder bis zu 50 Kommentare auf einen einzigen Blog-Post (Likes und Boosts nicht mit gezählt) während über RSS (gemessen an Kommentaren über das WordPress Formular) und Webmentions vielleicht eine Reaktion im Monat kommt.
Es scheint wohl zum guten Ton zu gehören, dieser Tage einen Newsletter zu betreiben… und da ich das immerhin schon seit 2005 tue, dachte ich, ich mache auch mal etwas Werbung dafür!
Das Thema ist natürlich das „open, portable, interoperable, small, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social web“, was auch sonst.
Das Archiv mit alten Veröffentlichungen findet ihr hier und abonnieren könnt ihr ihn hier.
Viel Spaß beim Lesen 😉
Aber jetzt im Ernst: Warum sollte man einen Newsletter starten, wenn man schon ein Blog hat? Was ist der Unterschied außer die Art der Distribution?
In deutsch zu bloggen war eine bewusste Entscheidung!
Der Austausch über das „open, portable, interoperable, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted und federated social web“ findet hauptsächlich in englischer Sprache statt, und mir ist wichtig, das Thema speziell in Deutschland voranzutreiben.
Ich bin bisher aber nie wirklich davon ausgegangen, dass meine „Artikel“ auch für anders sprechende interessant sein könnten, bis Ray mir folgendes in die Kommentare schrieb:
For those of you like me who can’t read German but want to follow your blog via RSS, I found a way to have an RSS feed translated on the fly to whatever language you prefer:
I can confirm it works following the steps listed within — Feedbin pulls in your RSS feed in english for me now! : )
Thanks for all you do, Ray
Und was soll ich sagen… Seine Idee is großartig und super simpel… Einfach einen kleinen Service über Google Scripts bauen, der die Texte aus dem Feed automatisch übersetzt und dann wieder als Feed bereit stellt! Die Anleitung findet ihr auf labnol.org und mein etwas angepasstes Skript auf GitHub.
Matthias Pfefferle und Marcel Weiß sprechen über (fast) alle Aspekte von RSS und warum (nicht nur) für sie Feedreader und das Ökosystem rund um RSS immer noch wichtig ist.
Hier klicken, um den Inhalt von share.transistor.fm anzuzeigen.
‚Hier & Jetzt‘ kann man per RSS-Feedabonnieren und findet man natürlich auch bei Apple Podcast und in jeder Podcast-App.
RSS funktioniert am besten, wenn man nicht genau wissen muss wie es funktioniert und wenn man nicht lange nach einem Feed suchen muss.
Ich hab mal drei (vermeintliche) Verbesserungen ausprobiert um die Feeds auf meinem Blog etwas sichtbarer und nutzbarer zu gestalten.
Discovery
WordPress Posts lassen sich über diverse Mechanismen kategorisieren, sei es über Tags, Kategorien oder über Post-Formats. Gerade bei Blogs auf denen viel und zu unterschielichsten Themen geschrieben wird, kann es sinnvoll sein, nicht den kompletten Blog zu abonnieren.
Um das zu verbessern hab ich in meinem Theme zwei Dinge gemacht:
Ich hab Feeds für die verschienen Post-Formats (Quote, Video, Audio, Artikel, …) gebaut.
Ich hab rel-alternate Links gebaut, die die verschiedenen Feeds eines Posts (Tag-Feeds, Kategorie-Feeds und Post-Formal-Feeds) verlinken.
Wenn ihr versucht, die entsprechende Post/Blog-URL in einem gängigen Feed-Reader zu abonniert, sollten euch diese Links in einem dropdown oder ähnlichem vorgeschlagen werden.
HTML-Feeds
Chris Aldrich hat sich in einem Kommentar gefragt, ob es nicht möglich ist, den SubToMe Button, auch direkt in einem Feed zu nutzen:
This [How to style RSS feed] seems like quite a clever way of adding some human readable styling to RSS feeds. While it seems like yet another side-file, it could be a useful one. I think if I were implementing it I’d also want to include a SubToMe universal follow button on it as well
How to style RSS feed – Let’s create a beautiful RSS feed UI for human before its dead in next year again.
Also hab ich mir mal die Mühe gemacht, meinen RSS-Feed mit XSLT und CSS zu „stylen“ um dann einen SubToMe Button mit einzubauen. Mal gespannt ob es hilft!?!
/follow
Marcus Herrmann hat vor ein paar Monaten vorgeschlagen eine /feeds URL zu etablieren:
Personal website owners – what do you think about collecting all of the feeds you are producing in one way or the other on a /feeds page? You can put your blog feed there, but also RSS generated from your Twitter account (via RSS Box), Mastodon updates, or even the starred items of the feeds you consume (if you happen to use Feedbin).
Letzte Woche war WordCamp Europe. Mit weit über 8000 Teilnehmern war es das bisher größte online WordCamp! Bei der Größe ist es klar, dass man auch eine ganze Menge neuer und interessanter Leute trifft. Also schnell auf Twitter und allen folgen!
Ich war auf dem größten online Event, von dem wohl am meisten verbreiteten Indie/OpenSource CMS und ich habe Personen, die ich dort kennen gelernt habe, über Twitter kontaktiert!
Warum?
Warum kam ich auf die Idee, Twitter zu benutzen, anstatt ihre Blogs zu abonnieren?
Auch auf den WordCamp Badges taucht lediglich das Twitter Handle auf und es wird nirgends das eigene Blog erwähnt.
Eigentlich ist die Antwort klar… Twitter ist ein soziales Netwerk dessen Kern-Kompetenz das Folgen anderer User ist. Außerdem findet der ganze Prozess an einer Stelle statt (twitter.com) und den Twitter-Handle kann man sich zudem leicht merken. Keine komplizierte Domain… keine Feed-URL… keine E-Mail Adresse… einfach nur @username…
Wie sieht das Folgen oder Befreunden bei Blogs aus? Ist es das Abonnieren des Feeds? Das heraussuchen der E-Mail Adresse über das Impressum? Das Bookmarken der Kontakt-Seite?
Es gibt leider keine einfache Alternative um einem Blog zu „folgen“.
Aber gehen wir mal davon aus, das Abonnieren des Feeds käme dem am nächsten… Wie bekomme ich die richtige Feed URL heraus? Bei WordPress ist das noch relativ einfach, da die URLs standardisiert sind, aber wie sieht es mit anderen Systemen aus?
People create more content than ever before – but siloed away in the Facebooks, Twitters, Instagrams and Mediums of the world. RSS is considered as something that can’t be monetized in our attention economy and is therefore on its way out. Even when personal blogs offer a feed, it is not obvious anymore in the browser user interface. When I stumble over an interesting blog and want to subscribe to it, I open the dev tools of my browser (which is kind of a knee jerk reaction in my profession anyway) and search the source code for a subscribable URL.
[…]
Personal website owners – what do you think about collecting all of the feeds you are producing in one way or the other on a /feeds page?
Ich mag die Idee, aber ich glaube nicht dass sie das oben beschriebene Problem löst. Es mag sein, dass es durch eine /feeds Seite einfacher ist, den richtigen Feed zu finden, es setzt aber auch voraus, dass man weiß was ein Feed, was RSS, oder was Atom ist.
Was wir eigentlich brauchen ist aber eine Art Indie-Follow oder Indie-Subscribe Button.
Chris Aldrich spricht in seiner Antwort auf Markus‘ Blogpost ein paar wichtige Punkte an.
Worse, suppose I click over to a /feeds page, as an average person I’m still stuck with the additional burden of knowing or learning about what a feed reader is, why I’d need or want one, and then knowing what RSS is and how I might use that. I might see a one click option for Twitter or Mastodon, but then I’m a mile away from your website and unlikely to see you again in the noise of my Twitter feed which has many other lurking problems.
Chris erwähnt SubToMe als bisher einzige offene Alternative, die einem Indie-Follow Button noch am nächsten kommt.
One of the best solutions I’ve seen in the past few years is that posited by SubToMe.com which provides a single, customizable, and universal follow button. One click and it automatically finds the feeds hidden in the page’s code and presents me with one or more options for following it in a feed reader.
Damit hat er leider recht!
[subtome type=“logo“ caption=“Follow!“ description=“Hier ein SubToMe Beispiel-Button:“]
Es gab in den letzten 10 Jahren diverse Ideen, die ein dezentrales „Follow“ ermöglicht hätten: XAuth, WebIntents, Custom-Schemes, WebActions und Rel-Subscribe. Leider hat sich aber keines dieser Format durchgesetzt. Die Gründe dafür reichen von einem Extrem zum anderen.
We didn’t specifically solve a single use case well other than connecting apps. The broad verb-space meant that a lot of developers wanted to design their own actions. I believe that this diluted the message of intents, and is something that if I had researched the Android ecosystem more effectively at the time, I would have probably constrained the verb eco-system to a couple of small but well defined cases.
Die Prüfung der Nutzungsdaten und der Anforderungen zur technischen Wartung dieser Funktionen (unter Berücksichtigung der Tatsache, dass Ihnen bereits alternative Reader für RSS/Atom-Formate zur Verfügung stehen) brachte die Erkenntnis, dass die Funktionen einen unverhältnismäßig großen Aufwand in Bezug auf Wartung und Sicherheit im Verhältnis zu ihrer Anwendung erfordern.
Auf der anderen Seite hat Mozilla schon 2010 einen Artikel über „RegisterProtocolHandler Enhancing the Federated Web“ geschrieben, in dem sie aufzeigen, wie ein dezentraler Follow-Button für das Fediverse funktionieren könnte und theoretisch auch immernoch funktioniert!
