Data publikacji: 29 października 2025 r.
Chrome zamierza 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ło XSLT, w tym interfejs XSLTProcessor JavaScript API i instrukcję przetwarzania XSLT. Planujemy wycofać obsługę wersji 158 (17 listopada 2026 r.). Projekty Firefox i WebKit również zapowiedziały usunięcie XSLT z mechanizmó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. Najnowsze informacje znajdziesz też w artykule o stanie platformy Chrome.
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 type="text/xsl" ... ?>).
Oś czasu w Chrome
Chrome oferuje ten abonament:
- Chrome 142 (28 października 2025 r.): dodanie do Chrome wczesnych komunikatów ostrzegawczych w konsoli.
- Chrome 143 (2 grudnia 2025 r.): oficjalne wycofanie interfejsu API – w konsoli i w Lighthouse zaczną się wyświetlać komunikaty ostrzegawcze o wycofaniu.
- Chrome 145 (2 grudnia 2025 r. Canary): wczesne ostrzeżenie – w wersjach Canary, deweloperskiej i beta domyślnie wyłączamy XSLT.
- Chrome 146 (10 marca 2026 r.): zasady Enterprise (EP) są dostępne do testowania. Umożliwia to firmom wcześniejsze testowanie wyłączania XSLT, a także dalsze korzystanie z funkcji po dacie ich usunięcia.
- Chrome 152 (25 sierpnia 2026 r.): wersja próbna origin jest dostępna do testowania. Pozwalają one witrynom nadal korzystać z funkcji po dacie ich usunięcia.
- Chrome 154 (22 września 2026 r.): wczesne ostrzeżenie – w wersjach Canary, deweloperskiej i beta Webview zacznie się domyślnie wyłączać XSLT.
- Chrome 158 (17 listopada 2026 r.): XSLT przestanie działać w wersjach stabilnych u wszystkich użytkowników z wyjątkiem uczestników testowania origin i użytkowników podlegających zasadom firmy.
- Chrome 176 (17 sierpnia 2027 r.): wersja próbna origin i zasady Enterprise przestają działać. Funkcja XSLT jest wyłączona 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 XSLTProcessor JavaScript API, który może służyć 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 oficjalną rekomendacją 1.0 firma Microsoft podjęła wczesną inicjatywę, dostarczając własną implementację opartą na roboczej wersji W3C w Internet Explorerze 5.0, wydanym w marcu 1999 r. 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 XSLT 2.0, a w 2017 roku – wersja XSLT 3.0. Wprowadzono w nich zaawansowane funkcje, takie jak wyrażenia regularne, ulepszone typy danych i możliwość przetwarzania 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 rozwojem wykorzystania formatu JSON jako formatu przesyłania danych oraz bibliotek i frameworków JavaScriptu (takich jak jQuery, React i Vue.js), które oferują bardziej elastyczną i wydajną manipulację DOM i szablonami, doprowadził do znacznego spadku wykorzystania XSLT po stronie klienta. Jego rolę w przeglądarce w dużej mierze przejęły technologie oparte na języku 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 transformacje, takie jak libxslt (używana przez przeglądarki Chromium), to złożone, starsze bazy kodu C/C++. Ten typ kodu jest notorycznie podatny na luki w zabezpieczeniach pamięci, takie jak przepełnienie bufora, co może prowadzić do samowolnego wykonania kodu. Na przykład audyty bezpieczeństwa i systemy śledzenia błędów wielokrotnie wykrywały w tych parserach luki w zabezpieczeniach o wysokim stopniu ważności (np. CVE-2025-7425 i CVE-2022-22834, w obu przypadkach w bibliotece libxslt). Ponieważ XSLT po stronie klienta jest obecnie rzadko używaną funkcją, biblioteki te są znacznie rzadziej poddawane konserwacji i kontroli bezpieczeństwa niż podstawowe mechanizmy języka JavaScript. Stanowią one bezpośrednią, potężną powierzchnię ataku do przetwarzania niezaufanych treści internetowych. XSLT jest źródłem kilku niedawnych 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ść.
Co więcej, pierwotny cel XSLT po stronie klienta, czyli 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 łańcuch narzędzi jest aktywnie rozwijany, korzysta z ogromnych inwestycji w bezpieczeństwo 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 podejmowane tylko w Chrome i Chromium: pozostałe 2 główne mechanizmy przeglądarek również obsługują usuwanie XSLT z platformy internetowej: WebKit i Gecko.
Z tych powodów wycofanie i usunięcie XSLT zmniejsza powierzchnię 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 deweloperów.
Zwiększanie bezpieczeństwa analizy XML
Podobnie jak w przypadku poważnych problemów z bezpieczeństwem w libxslt, poważne problemy z bezpieczeństwem zostały niedawno zgłoszone 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 analizą XML w Chromium, planujemy wycofać użycie biblioteki libxml2 i zastąpić analizę XML bezpieczną dla pamięci biblioteką do analizy XML napisaną w języku Rust. Co ważne, nie usuniemy z przeglądarki XML-a. Rozważamy tylko usunięcie XSLT. Chcemy, aby zastąpienie biblioteki libxml2 było dla programistów stron internetowych całkowicie przejrzyste.
XML + CSS nie są usuwane
Ważne jest, aby odróżnić wycofanie XSLT<?xml-stylesheet type="text/xsl" ... ?> od samej instrukcji przetwarzania<?xml-stylesheet ... ?>, która pozostaje obsługiwana w przypadku użycia z CSS. Możesz nadal używać instrukcji przetwarzania z elementem type="text/css", aby stosować standardowe reguły układu i projektu do danych pierwotnych, tak jak w przypadku kodu HTML. Na przykład:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
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 XML API 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 zdecydowanie największą z nich jest biblioteka Saxonica (zobacz obszerną dokumentację 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.
Kod polyfill
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...
Aby wywołać polyfill i przekształcić dokument za pomocą arkusza stylów XSLT, możesz dodać 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, które korzystają z 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 formę czytelną dla człowieka, gdy są one wyświetlane bezpośrednio w przeglądarce. Główny przypadek użycia to 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 odczytać, a nie sam surowy kod XML.
W tym przypadku użycia są 2 możliwości: Standardowy sposób dodawania tego elementu w HTML-u polega na umieszczeniu na stronie (opartej na HTML-u) znaku <link rel="alternate" type="application/rss+xml"> zamiast jawnego (widocznego dla użytkownika) znaku <a
href="something.xml">, który użytkownicy mogą przypadkowo kliknąć. To rozwiązanie umożliwia czytnikom RSS znajdowanie kanału, gdy użytkownik wklei tylko adres URL witryny, a także pozwala użytkownikom zobaczyć zwykłą zawartość HTML bez mylenia jej 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"></script>. Dzięki temu zachowane zostanie dotychczasowe działanie transformacji opartej na XSLT do HTML.
Nie powinno to wpłynąć 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, dlatego 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
Programiści 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, 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.
Jeśli w Chrome wystąpi konkretny problem związany z wycofaniem XSLT, zgłoś błąd.
Jak wykrywać użycie XSLT
Ogólnie rzecz biorąc, wycofane funkcje, takie jak XSLT, można wykryć w bazie kodu na kilka sposobów. W tej sekcji opisujemy 2 z nich.
Interfejs Reporting API
Reporting API to ogólny mechanizm raportowania, który umożliwia aplikacjom internetowym raportowanie różnych funkcji i warunków platformy, w tym wycofywania funkcji. Aby skonfigurować raportowanie wycofania XSLT, możesz użyć takiego fragmentu kodu:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
Zobacz ten kod w akcji na CodePen
Raport o starszych technologiach w firmie
Administratorzy firm mogą używać raportu o starszych technologiach do automatycznego zbierania informacji o użyciu wycofanych funkcji i przedstawiania ich w sposób przyjazny dla użytkownika. Więcej informacji o włączaniu tej funkcji znajdziesz w tym artykule w Centrum pomocy Google.