Chrome und Edge schaffen XSLT ab – für Suchmaschinen ändert sich nichts, für Menschen schon
Chrome and Edge are removing XSLT: what breaks and what does not
Am 17. November 2026 entfernt Chrome 158 die clientseitige XSLT-Unterstützung; Edge folgt mit derselben Engine. Betroffen sind alle XML-Dateien mit einer <?xml-stylesheet?>-Anweisung – darunter Sitemaps von WordPress mit gängigen SEO-Plugins. Crawler und Suchmaschinen parsen das XML unverändert, doch für Menschen verwandeln sich formatierte Tabellen in rohen XML-Code. Google begründet den Schritt mit Sicherheitsrisiken in veralteten C-Bibliotheken und verweist auf nur 0,02 Prozent der Seitenaufrufe. Kritiker sehen vor allem Behördenportale betroffen.
Der Kostentreffer dieser Änderung trifft überhaupt nicht die SEO-Teams; er trifft öffentliche Stellen, die maschinenlesbare Daten veröffentlicht und sie auf dem billigsten Weg, den die Plattform bot, für Menschen lesbar gemacht haben.
- cousin_it
Als ich zum ersten Mal erfuhr, dass XSLT abgeschafft wird, war ich neugierig, wie man dasselbe in JS erreichen kann (clientseitiges Templating, das während des Seitenladens stattfindet, ohne jegliches "Flash of Content"). Es stellt sich heraus, dass es dafür einen sehr schönen Weg gibt, indem man Inline-Skripte verwendet, die Elemente neben document.currentScript anhängen. Lean Rada hat hier darüber geschrieben: https://leanrada.com/notes/inline-rendering-currentscript/ und ich habe auch darüber geschrieben: https://vladimirslepnev.me/write
- Telaneo
Zumindest Firefox wird es noch haben, obwohl ich bei der Art und Weise, wie Mozilla drauf ist, nicht überrascht wäre, wenn sie nachziehen würden.
Ich empfinde genauso wie bei der Entfernung der Flash-Unterstützung: Es ist gut, dass wir zu besseren Dingen übergehen, aber das hilft nicht, wenn es keine besseren Dinge gibt, zu denen man übergehen kann.
Was ist der einfache Go-to-Weg, um webbasierte Spiele zu erstellen, mit denen Kinder herumspielen können? Es war Flash, und jetzt ist es nichts. Wie richtet man einen RSS-Feed ein, der nicht einfach rohes XML auf den Benutzer knallt? Bald wird es kein XSLT mehr sein, aber ich sehe keinen guten Ersatz (noch nerviger ist die Tatsache, dass Browser früher Funktionen hatten, um RSS-Feeds selbst zu verarbeiten, und XSLT wurde verwendet, um dieses Problem zu umgehen, aber jetzt gibt es nichts mehr zum Umgehen).
- mcculley
Ich verwende immer noch XSLT. Ich benutze es seit 26 Jahren. Ich generiere XML-Dokumente im Backend und wandle sie für verschiedene Berichte in HTML um. XSLT hat viele Funktionen und eine Mächtigkeit, die neueren Templating-Sprachen fehlen.
Ist eine dieser neueren Templating-Sprachen es wert, dass ich wechsle?
- Trustable8
Schade, in den XHTML-Tagen war XSLT eine Spezifikation, die die Modularität von Websites so viel sauberer hätte machen können. Ich habe einmal ein frühes Website-Erstellungstool erstellt, das separate Komponenten mit XSLT zusammenführte – es war wirklich leistungsstark in den Tagen, bevor JavaScript ohne jQuery nutzbar war. Allerdings wurde XHTML zugunsten von HTML5 aufgegeben, und XSLT war danach so ziemlich nutzlos. Es hat sich gut geschlagen, so lange zu überleben; ich vermute, es wurde hauptsächlich beibehalten, um XML-Dateien zu stylen.
- cosmic_cheese
Es kommt mir verrückt vor, dass dies bis heute der einzige weit verbreitete Weg war, gemeinsame HTML-Bestandteile wie Header, Navigation und Footer einzubinden, ohne dass an einem der beiden Enden etwas Dynamisches passiert. Es ist so ein grundlegender und häufiger Anwendungsfall, der so schlecht abgedeckt ist.