Vorschlag, Erwähnungen von XSLT aus der HTML-Spezifikation zu entfernen
(github.com/whatwg)- Es wurde ein Pull Request vorgeschlagen, der XSLT-bezogene Erwähnungen aus der HTML-Standarddokumentation entfernen soll
- Der Antragsteller erklärt, dass in wichtigen Browsern wie Chrome, Firefox und Safari entsprechende Implementierungsfehler gemeldet wurden und zudem Test- und Dokumentationsprobleme in Arbeit sind
- Gegenstimmen verweisen auf Kompatibilitätsprobleme bei bestehenden Websites und auf Lesbarkeitsprobleme, da XML-Dokumente beim Entfernen von
<?xml-stylesheet?>kaputtgehen könnten - Einige Entwickler betonen, dass XSLT weiterhin in Regierungsdokumenten, RSS und eingebetteten Umgebungen verwendet wird
- Es wird die Sorge geäußert, dass Entscheidungen, die sich stark an großen Browser-Anbietern orientieren, zu einer Einschränkung der Offenheit des Webs und seiner historischen Vielfalt führen könnten
Überblick über den Pull Request
- PR-Titel: Remove mentions of XSLT from the html spec
- Antragsteller: mfreed7
- Ziel: whatwg/html:main
- Zugehöriges Issue: #11523
- Für Chromium, Gecko und WebKit liegen entsprechende Implementierungsfehlerberichte vor
- Relevante Materialien wie die MDN-Dokumentation und HTML AAM sollen aktualisiert werden
Zentrale Gegenargumente
gucci-on-fleek (2025-08-15)
- Es müsse die Nutzungsstatistik und Größenordnung von Websites berücksichtigt werden
- Große Websites könnten aktualisiert werden, doch bei kleinen/persönlichen Websites bestehe die Sorge vor dauerhaft gebrochener Kompatibilität, da sie teils seit Jahrzehnten nicht gepflegt werden
- Das Entfernen von
XSLTProcessor()würde nur eine JS-Funktion einschränken, aber das Entfernen von<?xml-stylesheet?>hätte zur Folge, dass XML-Dokumente überhaupt nicht mehr angezeigt werden - Frühere veraltete HTML-Funktionen (
<font>,<align>,<xmp>) funktionieren weiterhin, doch diesmal gehe es um eine beispiellose Änderung, die ganze Dokumente beschädigen würde - Hervorgehoben wird das Risiko, dass der Zugang zu wichtigen Materialien wie alten Archiven und Universitäts-Websites blockiert werden könnte
nomis (2025-08-18)
- Es werden konkrete Anwendungsbeispiele für XSLT genannt
- Persönliche Einsatzbeispiele
- Komplexe XML-Daten in HTML-Tabellen umwandeln
- Dynamisches XML auf Mikrocontrollern mit Speicherbeschränkungen in statisches XSLT umwandeln
- Ein JS-Polyfill, das libxml2 vollständig einbindet, ist unrealistisch; das Entfernen der Browser-Unterstützung komme faktisch einer erzwungenen Neuimplementierung gleich
jonsterling (2025-08-18)
- Kritisiert wird die Realität, dass Browser-Anbieter die Webplattform faktisch monopolartig definieren
- XSLT trage weiterhin zu vielfältigen und kreativen Web-Anwendungen bei; eine Entfernung würde das Open Web schwächen
- Unter Verweis auf das Prinzip, dass „das Web uns allen gehört“, wird betont, dass Geschichte und Vielfalt respektiert werden müssten
Zustimmung und nächste Schritte
- domenic (2025-08-19): positive Reaktion und Hinweis, dass auch die XSLT-Erwähnungen in der DOM-Spezifikation aktualisiert werden sollten
- mfreed7 (2025-08-19): Antwort, dass dafür auch ein separater PR für die DOM-Spezifikation eingereicht werde
Zusammenfassung
- Die Entfernung von XSLT ist als Teil der Bemühungen zur Vereinfachung und Modernisierung von Browsern vorgeschlagen worden
- Die Gegenseite warnt jedoch vor Schäden bei Kompatibilität bestehender Dokumente, Zugänglichkeit von Regierungs- und Wissenschaftsdaten sowie der Vielfalt des Open Web
- Die Diskussion geht damit über eine rein technische Entscheidung hinaus und berührt auch die philosophische Frage, wer eigentlich über Webstandards entscheidet
1 Kommentare
Hacker-News-Kommentar
Es gibt einige bemerkenswerte Punkte
Diese Entscheidung ist keine Alleinaktion von Chrome; im Issue-Tracking und in den Protokollen der einschlägigen Standardisierungstreffen ist zu sehen, dass Vertreter aller großen Browser ihre Zustimmung signalisiert haben
Auch der jüngste Tagesordnungspunkt wurde von einem Mozilla-Ingenieur vorgeschlagen
Dass ein PR eingereicht wurde, bedeutet nicht, dass er sofort gemergt wird; es gibt noch etliche unerledigte Punkte
Da aber mehrere Browser-Vendoren zustimmen, ist die Wahrscheinlichkeit eines Merges hoch
Das Issue zur Frage, ob XSLT von der Webplattform entfernt werden soll, dient nicht dazu, Meinungen aus der Community einzusammeln, sondern ist ein Diskussions-Issue für die Maintainer der HTML-Spezifikation
Das Issue wurde zwar von einem Chrome-Ingenieur eröffnet, aber Mozilla-Ingenieure haben das Thema mehrfach in Meetings angesprochen, und es gab bereits zuvor einen Vendor-Konsens
Es wurden bereits schwerwiegende Sicherheitslücken gefunden
Auch der Haupt-Maintainer von libxslt ist direkt zurückgetreten
Das Wort Chrome wurde aus dem Titel entfernt
Der ursprünglich eingereichte Titel lautete: "Chrome intends to remove XSLT from the HTML spec"
Laut Chromes Telemetriedaten gibt es kaum Websites, die XSLT tatsächlich verwenden
Damit lässt sich zumindest anhand von Daten bestätigen, dass der Vorschlag keine großen Auswirkungen auf das gesamte Web hätte
Ich bin ein Entwickler, der früher bei Mozilla und Google (dem Chrome-Team) gearbeitet hat
Ich verstehe, dass Chrome/Blink, Safari/Webkit und Firefox/Gecko alle die Entfernung von XSLT unterstützen, aber zwei dieser Projekte leiden unter Ressourcenmangel, und eines davon neigt stark dazu, neue Features aggressiv hineinzudrücken
Auch Safari- und Firefox-Entwickler haben Gründe, eine solche Änderung zu begrüßen
Entscheidend ist nicht, ob „autoritative Leute das für eine gute Idee halten“, sondern ob „diese Idee negative Auswirkungen auf die Webplattform und Milliarden von Nutzern haben wird“
Selbst wenn nur 0,1 % von Milliarden Menschen davon abhängen, ist das immer noch erheblich
Wenn es wirklich niemand nutzt, gäbe es auch keinen Grund für ein Polyfill
Es ist nicht wünschenswert, daraus ein Nullsummenspiel zu machen, bei dem man für jedes neue Feature zwingend ein altes entfernen muss
Google hat ausreichend Kapital und Personal und entscheidet sich trotzdem bewusst dagegen, XSLT weiter zu unterstützen
Es gab oft Fälle, in denen etwas direkt vorangetrieben wurde, nur weil mehrere Vendoren zustimmten
So war es auch bei der Entfernung von confirm/prompt, die am Ende aber auf unbestimmte Zeit verschoben wurde
Es gibt bei Google ein offizielles Dokument zum Prozess der Feature-Entfernung
Google feature removal doc
Die „Unterstützung allein durch die Vendoren“ hat die tatsächliche Nutzung offenbar nicht sauber geprüft
Nach den beiden Threads, die ich gelesen habe, hat Google um Feedback gebeten, und fast das gesamte Feedback lautete: „Macht das nicht“
Googles Reaktion wirkte jedoch wie: „Danke für eure Meinung, wir machen es trotzdem!“
Falls es wirklich um Sicherheit geht, hätte es viele Alternativen gegeben: Open Source unterstützen, auf eine sicherere Bibliothek wechseln oder den Support innerhalb einer JS-Sandbox erhalten; das meiste davon wurde ignoriert
Es gab außerdem fortlaufend Wünsche nach Unterstützung neuerer Versionen wie XSLT 3.0, die aber nicht umgesetzt wurden
Obwohl XSLT eine Technologie ist, die das offene Web unterstützt, hat Google seit etwa zehn Jahren den Support reduziert, sie vernachlässigt und unter Verweis auf sinkende Nutzung immer wieder versucht, sie zu entfernen
Gerade jetzt, wo XSLT wieder etwas an Popularität gewinnt, entsteht der Eindruck, man wolle es töten, bevor ein offener Konkurrent daraus entsteht
Zugehöriges Issue
Zur Behauptung, ein Großteil des Feedbacks habe „Macht das nicht“ gelautet: Der betreffende Thread wurde wegen böswilliger Kommentare, Verleumdungen usw. früh gesperrt
Kommentare wie „Das ist eine gute Idee“ werden üblicherweise seltener gepostet, sodass es leicht so aussehen kann, als gäbe es nur Gegenstimmen
Alle haben sich extrem im Ton vergriffen, und deshalb wurde die Diskussion beendet; das war letztlich selbstverschuldet
Wenn die Stimmen mit „Bitte nicht“ keine echten Nutzer sind oder keine zwingenden Gründe nennen können, ist es nachvollziehbar, wenn das Entwicklungsteam sie ignoriert
Die Bitte um Feedback ist keine einfache Ja/Nein-Abstimmung
Es wäre schön, wenn sich XSLT 3.0 in eine JS/wasm-Sandbox verlagern und dort unterstützen ließe
Das würde zwar etwas Performance kosten, könnte aber die Vorteile beider Seiten vereinen
XML lässt sich durch Eigenschaften wie Versionsschema und Namespaces vergleichsweise leicht integrieren
Anders als bei JS-Frameworks wie Angular sind verlässliche Datenverträge möglich
Dank der Reife der XML-Familie gibt es viele spezialisierte Tools, sodass man XML/XSD in der Praxis nicht einmal zwingend direkt als Text bearbeiten muss
Google kündigt dem Web gewissermaßen in „Frageform“ an, was als Nächstes passieren wird
Einführung in frühere zugehörige Threads
Thread zum Thema XSLT-Entfernung
XSLT - ein natives, Zero-Config-Build-System für das Web
Es gibt auch andere Threads, die wegen dieses Themas geflaggt wurden
Google is killing the open web, today
Ich frage mich, ob Browser überhaupt eingebauten Support für eine bestimmte Template-Engine wie XSLT brauchen
Das ist keine Text-Engine wie Jinja, aber es ließe sich auch in JS/wasm neu implementieren
Browser sind heute zu schwergewichtig, und neue Engines zu entwickeln ist schwierig
Ich hätte gern einen einfacheren Standard nur für „minimale Browser“ mit Grundelementen wie Basis-Tags und Layout
Auch WebAudio, Canvas usw. ließen sich als wasm-Module implementieren (und würden so auch Fingerprinting erschweren)
XSLT ist eine „Spezifikation“ für eine Template-Engine, nicht eine bestimmte Engine; es gibt verschiedene Implementierungen
Mozilla verwendet statt libxslt transformiix
Jinja ist einfache Textverarbeitung, XSLT arbeitet auf Node-Ebene und ist dadurch deutlich leistungsfähiger
Transformationen in JS sind viel langsamer als native XSLT-Transformationen, und das Caching der Ergebnisse ist ebenfalls schwieriger
Ich verstehe die Sichtweise, XSLT sei veraltet, aber in Sachen Performance war es in den letzten 20 Jahren ein versteckter Trumpf
Google wird das Problem am Ende wahrscheinlich mit einer Alternative wie AMP überdecken wollen
Dass Browser so schwergewichtig sind, ist Googles Schuld
XSLT ist die Sprache (die Spec), nicht die Engine
Eine Änderung der Implementierung hin zu JS/wasm ist eine Frage der internen Umsetzung und nicht dasselbe wie die Entfernung der Sprache von der Webplattform
Audio oder Canvas sind grundlegende I/O-Funktionen des Browsers; sie nach wasm zu verlagern würde gravierende Probleme bei Performance und Kompatibilität verursachen
Teile von Audio könnte man vielleicht in ein wasm-Blob verschieben, aber das gesamte System zu verlagern wäre schwierig
Bei Canvas-Kontexten oder WebGL ist die direkte Integration mit der GPU zentral, daher lässt sich das nicht in wasm abbilden
Solche Funktionen sind letztlich bereits grundlegende primitive APIs und damit nicht verhandelbar
Es wurde auch die Idee diskutiert, alten XSLT-Code als wasm zu verpacken, damit ältere Websites nicht kaputtgehen
Das wurde intern tatsächlich geprüft, letztlich aber verworfen
Ich finde, Funktionen, die sehr weit vom eigentlichen Web entfernt sind und nur von extrem wenigen genutzt werden, können durchaus entfernt werden
Aber Sicherheitslücken als Begründung anzuführen, finde ich nicht überzeugend
Solange nicht einmal geprüft wurde, ob ein memory-safe Paket existiert, ist das Argument wenig glaubwürdig
Es wird behauptet, die tatsächliche Nutzung liege bei 0,001 %
Die grundlegende Zusage der HTML-Spezifikation zu brechen, ist ein äußerst schwerwiegender Schritt
Umso erstaunlicher ist es, dass die Diskussion diesen Punkt nicht tiefgehend behandelt
HTML war einmal das Versprechen: „Das ist HTML. Darauf kannst du dich verlassen.“ Nun wird daraus eher: „Das ist im Moment HTML, aber niemand garantiert dir, dass es das auch in Zukunft bleibt“
Nach derselben Logik könnten künftig auch andere alte Technologien weiter gestrichen werden
Im Kern ist das ein Vorschlag, den „Long Tail“ des Webs abzuschneiden
Man sollte auch bedenken, dass viele später hinzugefügte Webtechnologien selbst irgendwann Teil dieses Long Tail werden und damit weitere Entfernungen nach sich ziehen könnten
Bei alternden Medien und alter Software denke ich allerdings auch, dass irgendwann der Punkt kommt, an dem Portierung, Emulation und Archivierung die richtige Antwort sind
Entscheidend ist ein Gleichgewicht zwischen genügend Zeit und Werkzeugen für die Umstellung und dem Vermeiden immer weiter anwachsener Komplexität
Wenn man sich die im eigentlichen PR entfernten Stellen ansieht, scheint es in HTML keine explizite Vorschrift zu geben, die XSLT-Unterstützung verlangt
Im Grunde ist die heftige Reaktion eher eine Reaktion auf die Browser-Unterstützung selbst
Der PR ist überraschend kurz
Seit WHATWG HTML als „Living Standard“ definiert, ist es faktisch keine feste Implementierungsspezifikation mehr, sondern eher eine geteilte Sicht darauf, woran Browser-Vendoren aktuell arbeiten
Deshalb wurde auch eine Versionsbezeichnung wie HTML5 abgeschafft und nur noch „HTML“ verwendet
Living Standard FAQ
HTML standard FAQ
Ironischerweise ist Google selbst einer der Hauptakteure, die HTML/CSS/Browser-Spezifikationen mit riesigen Mengen an Features aufgebläht haben
Wenn Google konsequent die Haltung vertreten hätte, Browser müssten leichtgewichtig bleiben und seltsame Dinge gehörten in JS-Bibliotheken, wäre dieser Schritt zumindest nachvollziehbar gewesen, aber genau das war nie der Fall
Seit der Entfernung des FTP-Supports war das Schicksal von XSL bereits absehbar
Browser priorisieren tendenziell die Verringerung der Angriffsfläche über alles andere
Ich vermute, die nächsten Kandidaten für eine Entfernung wären XML-bezogene Funktionen wie SVG-SMIL-Animationsattribute oder MathML
Zugehöriger Thread
Mit SMIL kann man sequentielle Animationen anhand bestimmter Start- und Endzeitpunkte steuern, und genau hier sind CSS-Animationen noch unzureichend
In CSS bleibt dafür im Wesentlichen nur das Rechnen mit Zeitwerten
Auch Chromium hatte einmal die Absicht erklärt, SMIL zu entfernen, aber das war zu voreilig, weil CSS dafür noch nicht ausgereift genug war
In der Folge wurden diverse Hinweise und Dokumentationen zu SMIL ohne Aktualisierung liegen gelassen
Ich würde gern grundsätzlich fragen, ob das Reduzieren der Angriffsfläche wirklich gut oder schlecht ist
Techniker und normale Nutzer setzen hier oft unterschiedliche Prioritäten
Ich frage mich, wann der FTP-Support eigentlich entfernt wurde
Ich dachte, man könne in der Adressleiste immer noch
ftp://aufrufenDie XSLT-Implementierungen in Blink und WebKit sind sehr ineffizient
Ich finde diese Entscheidung bedauerlich, aber noch bedauerlicher ist, dass man keine Energie in eine modernere XSLT-Integration gesteckt hat
Die Nutzung war zwar umständlich, aber mit etwas Weiterentwicklung im Browser hätte daraus womöglich ein echter Konkurrent zu Frameworks wie React werden können
XML war, wenn man die unternehmensbedingte Überkomplexität einmal ausblendet, als Standard selbst äußerst leistungsfähig und eine großartige Technologie
Ich mochte es sehr, kleine und einfache XML-/Datenstrukturen direkt mit XSLT in HTML umzuwandeln
Mit nur ein wenig zusätzlicher Funktionalität, etwa um ausgewählte Elemente anders darzustellen, hätte sich das auch für statische Dokumente in vielen Fällen sehr gut geeignet
@whatwg soll das Issue mit der Begründung gesperrt haben, die Diskussion sei „überhitzt“, und nur noch für Mitwirkende geöffnet haben
Auf mich wirkte sie ziemlich vernünftig und ruhig; da fragt man sich, ob die Schwelle für „überhitzt“ davon abhängt, ob jemand einem bestimmten Vendor wohlgesonnen ist
Der Ausdruck „überhitzt“ wird oft so verstanden, dass man sich schlicht nicht mit Gegenpositionen befassen will
Das ist in anderen Communities wie Reddit ähnlich
Der einzige Kommentar, der darunter tatsächlich noch stehen blieb, stammt von einem Entwickler bei Google Chrome und lautet sinngemäß: „Gute Arbeit“
Das wirkt ein wenig peinlich
Es wurde auf Fälle hingewiesen, in denen im Issue-Tracker beleidigende Beschimpfungen, Verschwörungstheorien und politische Botschaften gepostet wurden
Unter solchen Umständen wird produktive Diskussion unmöglich, und die Repository-Verwalter haben kaum eine andere Wahl, als die Debatte schnell zu stoppen
Ich habe gehört, dass die Sperrung der Diskussion in diesem Repository in Wirklichkeit von einem Apple-Mitarbeiter veranlasst wurde
Trotzdem geben viele Menschen dafür dem Google-Mitarbeiter die Schuld, der das Issue eröffnet hat
Google hat in letzter Zeit zwar offene Diskussionen unter dem Banner der Community-Beteiligung geführt, versucht danach aber dennoch, alle Einwände zu ignorieren und seine Linie durchzusetzen
Zugehöriges Issue
Man sollte das Thema veraltete Webelemente grundsätzlich breiter diskutieren
Für mich persönlich hat es großen Wert, dass auch alte Webseiten weiterhin korrekt funktionieren
Gerade weil HTML/JS die Kompatibilität gewahrt haben, laufen sogar jahrzehntealte Seiten mit nur einem TLS-Zertifikat immer noch problemlos
Andererseits kann man nicht jede Alttechnologie für immer unterstützen
Auch bei Flash ist man am Ende zu Emulatoren wie Ruffle übergegangen, um alte Spiele oder Websites weiter erlebbar zu machen
Langfristig könnten auch spezialisierte Browser oder Emulatoren für alte Rendering-Stacks eine praktikable Alternative sein
Dafür gibt es bereits eine XSLT-Polyfill-Erweiterung
Chrome möchte sie jedoch nicht offiziell ausliefern oder pflegen
Das ist eine sehr ähnliche Situation wie bei Ruffle