Data publikacji: 29 października 2025 r.
Zespół Chrome planuje wycofać i usunąć XSLT z przeglądarki. W tym dokumencie znajdziesz szczegółowe informacje o tym, jak przenieść kod przed jego usunięciem pod koniec 2026 r.
Chromium oficjalnie wycofał XSLT, w tym interfejs JavaScript API XSLTProcessor i instrukcję przetwarzania arkusza stylów XML. Planujemy wycofać obsługę tej wersji 17 listopada 2026 r. (wersja 155). Projekty Firefox i WebKit również zapowiedziały usunięcie XSLT z silników przeglądarek. W tym dokumencie znajdziesz informacje o historii i kontekście, wyjaśnienie, dlaczego usuwamy XSLT, aby zwiększyć bezpieczeństwo Chrome, oraz wskazówki dotyczące migracji przed usunięciem tych funkcji z przeglądarki.
Co zostanie usunięte?
W przeglądarce są 2 interfejsy API, które implementują XSLT. Oba zostaną usunięte:
- Klasa XSLTProcessor (np.
new XSLTProcessor()). - Instrukcja przetwarzania XSLT (np.
<?xml-stylesheet … ?>).
Oś czasu w Chrome
Chrome oferuje ten abonament:
- Chrome 142 (28 października 2025 r.): dodanie do Chrome komunikatów konsoli z wczesnym ostrzeżeniem.
- Chrome 143 (2 grudnia 2025 r.): oficjalne wycofanie interfejsu API – w konsoli i w Lighthouse zaczną się wyświetlać komunikaty ostrzegawcze o wycofaniu.
- Chrome 148 (10 marca 2026 r., Canary): wersje Canary, deweloperska i beta zaczynają domyślnie wyłączać XSLT jako wczesne ostrzeżenie.
- Chrome 152 (25 sierpnia 2026 r.): testowanie origin trial (OT) i zasad Enterprise (EP). Umożliwiają one witrynom i przedsiębiorstwom dalsze korzystanie z funkcji po dacie ich usunięcia.
- Chrome 155 (17 listopada 2026 r.): XSLT przestanie działać w wersjach stabilnych dla wszystkich użytkowników z wyjątkiem uczestników testów Origin Trial i zasad dotyczących przedsiębiorstw.**
- Chrome 164 (17 sierpnia 2027 r.): zakończenie działania testowania origin i zasad firmy. XSLT jest wyłączone dla wszystkich użytkowników.**
Co to jest XSLT?
XSLT, czyli Extensible Stylesheet Language Transformations, to język używany do przekształcania dokumentów XML, zwykle na inne formaty, takie jak HTML. Do określania reguł tej konwersji używa pliku arkusza stylów XSLT i pliku XML zawierającego dane wejściowe.
Gdy przeglądarka otrzyma plik XML, który zawiera link do arkusza stylów XSLT, używa reguł z tego arkusza do przekształcenia, sformatowania i przekonwertowania surowych danych XML na uporządkowaną stronę (często HTML), którą można wyświetlić użytkownikowi.
Na przykład arkusz stylów XSLT może przyjmować następujące dane wejściowe XML:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
i ten arkusz stylów XSL:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/page/message">
<body>
<p>Message: <xsl:value-of select="."/></p>
</body>
</xsl:template>
</xsl:stylesheet>
i przetworzyć je na ten kod HTML, aby przeglądarka mogła go wyświetlić: HTML
<body>
<p>Message: Hello World.</p>
</body>
Oprócz instrukcji przetwarzania XSL pokazanej w poprzednim przykładzie istnieje też interfejs API JavaScript XSLTProcessor, którego można używać do przetwarzania lokalnych dokumentów XML za pomocą lokalnych arkuszy stylów XSLT.
Historia XSLT
16 listopada 1999 r. organizacja World Wide Web Consortium (W3C) zarekomendowała XSLT jako język do przekształcania dokumentów XML w inne formaty, najczęściej HTML, do wyświetlania w przeglądarkach internetowych. Przed wydaniem oficjalnej rekomendacji 1.0 firma Microsoft podjęła inicjatywę i w Internet Explorerze 5.0, wydanym w marcu 1999 r., wprowadziła własną implementację opartą na roboczej wersji W3C. Zgodnie z oficjalnym standardem Mozilla wdrożyła natywną obsługę XSLT 1.0 w Netscape 6 pod koniec 2000 roku. Inne popularne przeglądarki, w tym Safari, Opera i nowsze wersje Chrome, również zawierały natywne procesory XSLT 1.0, dzięki czemu na początku XXI wieku przekształcanie XML w HTML po stronie klienta stało się realną technologią internetową.
Sam język XSLT był dalej rozwijany. W 2007 roku ukazała się wersja 2.0, a w 2017 roku – wersja 3.0. Wprowadzono w nich zaawansowane funkcje, takie jak wyrażenia regularne, ulepszone typy danych i możliwość przetwarzania formatu JSON. Obsługa przeglądarek jednak nie rozwijała się. Obecnie wszystkie główne silniki przeglądarek internetowych zapewniają tylko natywną obsługę oryginalnego języka XSLT 1.0 z 1999 roku. Ten brak postępu w połączeniu z rosnącą popularnością formatu JSON jako formatu przesyłania danych oraz bibliotek i architektur JavaScript (takich jak jQuery, React i Vue.js), które oferują bardziej elastyczne i zaawansowane manipulowanie DOM i szablonami, doprowadził do znacznego spadku wykorzystania XSLT po stronie klienta. Jego rola w przeglądarce internetowej została w dużej mierze zastąpiona przez technologie oparte na JavaScript.
Dlaczego XSLT musi zostać usunięty?
Dalsze uwzględnianie XSLT 1.0 w przeglądarkach internetowych stanowi poważne i niepotrzebne zagrożenie dla bezpieczeństwa. Biblioteki bazowe, które przetwarzają te przekształcenia, np. libxslt (używana przez przeglądarki Chromium), to złożone, starsze bazy kodu C/C++. Ten typ kodu jest podatny na luki w zabezpieczeniach pamięci, takie jak przepełnienie bufora, które mogą prowadzić do wykonania dowolnego kodu. Na przykład audyty zabezpieczeń i systemy śledzenia błędów wielokrotnie wykrywały w tych parserach poważne luki w zabezpieczeniach (np. CVE-2025-7425 i CVE-2022-22834 (obie w libxslt). XSLT po stronie klienta jest obecnie rzadko używaną funkcją, dlatego biblioteki te są znacznie rzadziej konserwowane i sprawdzane pod kątem bezpieczeństwa niż podstawowe silniki JavaScriptu. Stanowią one jednak bezpośrednią i potencjalną powierzchnię ataku podczas przetwarzania niezaufanych treści internetowych. XSLT jest źródłem kilku ostatnich głośnych luk w zabezpieczeniach, które nadal zagrażają użytkownikom przeglądarek. Ryzyko związane z utrzymywaniem tej przestarzałej, podatnej na awarie funkcji znacznie przewyższa jej ograniczoną przydatność w dzisiejszych czasach.
Co więcej, pierwotny cel XSLT po stronie klienta – przekształcanie danych w kod HTML, który można renderować – został zastąpiony bezpieczniejszymi, wygodniejszymi i lepiej utrzymywanymi interfejsami API JavaScript. Nowoczesne tworzenie stron internetowych opiera się na takich elementach jak interfejs Fetch API do pobierania danych (zwykle w formacie JSON) i interfejs DOMParser API do bezpiecznego analizowania ciągów XML lub HTML w strukturę DOM w bezpiecznym środowisku JavaScript w przeglądarce. Frameworki takie jak React, Vue i Svelte zarządzają następnie renderowaniem tych danych w wydajny i bezpieczny sposób. Ten nowoczesny zestaw narzędzi jest aktywnie rozwijany, korzysta z ogromnych inwestycji w zabezpieczenia silników JavaScript i jest obecnie używany przez praktycznie wszystkich deweloperów stron internetowych. Obecnie tylko około 0,02% wczytań stron internetowych korzysta z XSLT, a mniej niż 0,001% – z instrukcji przetwarzania XSLT.
Nie jest to działanie ograniczone do Chrome ani Chromium: pozostałe 2 główne silniki przeglądarek również obsługują usuwanie XSLT z platformy internetowej: WebKit i Gecko.
Z tych powodów wycofanie i usunięcie XSLT zmniejsza obszar ataku przeglądarki dla wszystkich użytkowników, upraszcza platformę internetową i umożliwia skoncentrowanie zasobów inżynieryjnych na zabezpieczaniu technologii, które faktycznie obsługują nowoczesną sieć, bez praktycznej utraty możliwości dla programistów.
Zwiększanie bezpieczeństwa analizy XML
Podobnie jak w przypadku poważnych problemów z bezpieczeństwem w libxslt, niedawno zgłoszono poważne problemy z bezpieczeństwem w libxml2, która jest używana w Chromium do analizowania, serializacji i testowania poprawności XML. Aby rozwiązać przyszłe problemy z bezpieczeństwem związane z analizowaniem XML w Chromium, planujemy wycofać bibliotekę libxml2 i zastąpić analizowanie XML biblioteką napisaną w języku Rust, która jest bezpieczna pod względem zarządzania pamięcią. Co ważne, nie usuniemy z przeglądarki kodu XML. Rozważamy tylko usunięcie kodu XSLT. Chcemy, aby zastąpienie biblioteki libxml2 było dla programistów stron internetowych całkowicie przejrzyste.
Jak przeprowadzić migrację
Istnieje kilka alternatywnych ścieżek migracji.
JSON
W przypadku witryn w całości opartych na XML i XSL nie ma jednego uniwersalnego sposobu na przeprowadzenie migracji. Opcje migracji obejmują przeniesienie procesu przetwarzania XSLT na serwer i wysyłanie do klienta wyrenderowanego kodu HTML lub migrację punktów końcowych interfejsu API XML po stronie serwera do formatu JSON i wykonywanie renderowania po stronie klienta za pomocą JavaScriptu w celu przekształcenia JSON w HTML DOM i CSS.
XSLT po stronie klienta w JavaScript
Dostępnych jest kilka bibliotek XSLT po stronie klienta (opartych na JavaScript), ale największą z nich jest biblioteka Saxonica (zobacz obszerną dokumentację dotyczącą Saxonica). Implementacja wykracza daleko poza implementację XSLT 1.0 w przeglądarkach internetowych, ponieważ zapewnia pełną obsługę najnowszego standardu w wersji 3.0, a w przyszłości także standardu w wersji 4.0, który jest obecnie w trakcie opracowywania.
Watolina poliestrowa
Istnieje polyfill, który próbuje umożliwić dalsze działanie istniejącego kodu zależnego od implementacji XSLT 1.0 w przeglądarkach internetowych, ale nie korzysta z natywnych funkcji XSLT w przeglądarce. Polyfill znajduje się w GitHubie.
Polyfill zawiera funkcjonalny zamiennik klasy XSLTProcessor oparty na WASM, dzięki czemu istniejący kod JavaScript może nadal działać bez zmian:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Polyfill udostępnia też automatyczną funkcję narzędziową, która ułatwia zastępowanie dokumentów XML korzystających z instrukcji przetwarzania XSLT:
W przypadku oryginalnego pliku demo.xml, takiego jak ten:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Możesz dodać 1 wiersz, aby wywołać polyfill i przekształcić dokument za pomocą arkusza stylów XSLT, do którego odwołuje się ten wiersz:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
W tym przypadku nowy element <script> wczytuje polyfill, który wykrywa typ dokumentu XML i instrukcję przetwarzania XSLT, a następnie wczytuje go w sposób niewidoczny dla użytkownika, zastępując dokument.
Rozszerzenie
Istnieje też rozszerzenie Chrome, które można dodać do obsługiwanych przeglądarek. Zastosuje ono ten sam polyfill XSLT do wszystkich surowych stron XML zawierających instrukcje przetwarzania XSLT lub wywołania XSLTProcessor. Może to być przydatne w przypadku aplikacji, w których nie można zmienić źródłowego kodu XML ani XSLT, aby zachować funkcjonalność.
W szczególności, gdy XSLT jest wyłączony, Chrome wyświetla teraz baner z ostrzeżeniem, który zawiera link bezpośrednio do strony wyszukiwania rozszerzeń, aby ułatwić użytkownikom znalezienie rozszerzenia:
Konkretne przypadki użycia
W dyskusji na temat standardów HTML zidentyfikowano kilka konkretnych przypadków użycia. W tej sekcji omawiamy każdy z nich, aby zaproponować programistom publikującym obecnie zasoby XML przy użyciu XSLT dalsze działania.
Kanały RSS i Atom
W wielu istniejących kanałach RSS lub Atom XSLT jest używany do przekształcania surowych kanałów XML w format czytelny dla człowieka, gdy są one wyświetlane bezpośrednio w przeglądarce. Głównym zastosowaniem jest sytuacja, w której użytkownik przypadkowo kliknie link do kanału RSS witryny. Zamiast wklejać ten link do czytnika RSS, otrzyma sformatowaną odpowiedź w HTML-u, którą może przeczytać, a nie sam surowy kod XML.
W tym przypadku użycia są 2 możliwości: Standardowym sposobem na to w HTML-u jest dodanie <link rel="alternate" type="application/rss+xml"> do witryny (opartej na HTML-u), a nie dodawanie jawnego (widocznego dla użytkownika) <a
href="something.xml">, które użytkownicy mogą przypadkowo kliknąć. To rozwiązanie umożliwia czytnikom RSS znajdowanie kanału, gdy użytkownik wklei tylko adres URL witryny, ale pozwala też użytkownikom zobaczyć zwykłą zawartość HTML bez mylenia się z linkiem do zasobu XML. Jest to zgodne z normalnym paradygmatem internetowym, w którym HTML jest przeznaczony dla ludzi, a XML dla maszyn. Oczywiście nie rozwiązuje to problemu, gdy użytkownik po prostu „ma” link RSS z jakiegoś źródła i wkleja go do przeglądarki (zamiast do czytnika RSS).
Jeśli to rozwiązanie nie jest odpowiednie, polyfill oferuje inną ścieżkę. Jak wspomnieliśmy wcześniej, kanał XML RSS/Atom można rozszerzyć o jeden wiersz: <script
src="xslt-polyfill.min.js"
xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>. Dzięki temu zachowane zostanie dotychczasowe działanie transformacji opartej na XSLT do HTML.
Nie powinno to mieć wpływu na możliwość dalszego analizowania kodu XML przez czytnik RSS, ponieważ element <script> jest bezpośrednim elementem podrzędnym elementu głównego.
Dane wyjściowe interfejsu API dla urządzeń wbudowanych
Niektóre komercyjne urządzenia wbudowane mierzą lub w inny sposób generują dane XML, które są wykorzystywane przez użytkowników w sieci lokalnej. Niektóre z tych urządzeń generują pojedynczy plik danych XML, który za pomocą XSLT przekształcają w czytelny dla człowieka format HTML. Dzięki temu interfejs API można wyświetlać bezpośrednio w przeglądarce bez konieczności dodawania dodatkowego kodu na urządzeniu lub w przeglądarce.
Jest to bardzo specyficzny przypadek użycia, więc kształt rozwiązania może się różnić. W przypadku aplikacji, w których można aktualizować kod źródłowy urządzenia wbudowanego, można zastosować dowolną z opisanych wcześniej opcji (JSON, Polyfill). Wiele takich urządzeń jest jednak trudnych lub niemożliwych do zaktualizowania z różnych powodów. W takim przypadku najlepszym rozwiązaniem będzie prawdopodobnie rozszerzenie, ponieważ umożliwia ono przeglądarkom klientów dalsze odczytywanie danych w dokładnie taki sam sposób, bez modyfikowania urządzenia.
Lazy templating for web sites
Deweloperzy stron internetowych czasami używają XSLT po stronie klienta, aby zastosować znaczniki prezentacji do znaczników semantycznych. Działa to jak język szablonów leniwych, który jest oddzielony od ekosystemu JavaScript.
Istnieją 2 rozwiązania tego bardziej ogólnego problemu. W przypadku istniejącej witryny utworzonej w ten sposób najprostszym rozwiązaniem jest prawdopodobnie dodanie polyfillu, aby zachować dotychczasową funkcjonalność. Możesz też przeprowadzić transformację XSLT po stronie serwera i wyświetlić klientowi wynikowy kod HTML zamiast surowego kodu XML. Bardziej długoterminowym rozwiązaniem w przypadku takich usług byłoby przejście na nowocześniejszy framework oparty na JavaScript lub JSON.