Опубликовано: 29 октября 2025 г.
Chrome планирует отказаться от XSLT и удалить его из браузера. В этом документе подробно описано, как вы можете перенести свой код до удаления XSLT в конце 2026 года.
Chromium has officially deprecated XSLT, including the XSLTProcessor JavaScript API and the XSLT processing instruction . We intend to remove support from version 158 (November 17, 2026). The Firefox and WebKit projects have also indicated plans to remove XSLT from their browser engines. This document provides some history and context, explains how we are removing XSLT to make Chrome safer, and provides a path for migrating before these features are removed from the browser. For the latest updates, also see the Chrome Platform Status entry .
Что именно удаляется?
В браузере есть два API, реализующих XSLT, и оба будут удалены:
- Класс XSLTProcessor (например,
new XSLTProcessor()). - Инструкция обработки XSLT (например,
<?xml-stylesheet type="text/xsl" ... ?>).
Хронология для Chrome
В Chrome действует следующий план:
- Chrome 142 (28 октября 2025 г.): В Chrome добавлены сообщения раннего предупреждения в консоли.
- Chrome 143 (2 декабря 2025 г.): Официальное объявление API устаревшим — предупреждающие сообщения об устаревании начинают отображаться в консоли и в Lighthouse.
- Chrome 145 (2 декабря 2025 г., Canary ): В версиях Canary, Dev и Beta по умолчанию начинает отключаться XSLT в качестве раннего предупреждения.
- Chrome 146 (10 марта 2026 г.): Политика предприятия (EP) запущена для тестирования. Это позволит предприятиям как протестировать отключение XSLT на раннем этапе, так и продолжить использование функций после даты их удаления.
- Chrome 152 (25 августа 2026 г.): Запущена тестовая версия Origin Trial (OT) . Это позволит сайтам продолжать использовать функции и после даты их удаления.
- Chrome 154 (22 сентября 2026 г.): В версиях Webview Canary, Dev и Beta по умолчанию начинает отключаться XSLT в качестве раннего предупреждения.
- Chrome 158 (17 ноября 2026 г.): XSLT перестает работать в стабильных версиях для всех пользователей, кроме участников пробной версии Origin и участников корпоративной политики.
- Chrome 176 (17 авг. 2027 г.): Пробная версия Origin и корпоративная политика перестали работать. XSLT отключен для всех пользователей.
Что такое XSLT?
XSLT, или расширяемый язык преобразования таблиц стилей, — это язык, используемый для преобразования XML-документов, обычно в другие форматы, такие как HTML. Он использует файл таблицы стилей XSLT для определения правил этого преобразования и XML-файл, содержащий данные, используемые в качестве входных данных.
В браузерах, когда получен XML-файл, содержащий ссылку на таблицу стилей XSLT, браузер использует правила этой таблицы стилей для перегруппировки, форматирования и преобразования исходных XML-данных в структурированную страницу (часто HTML), которая может быть отображена для пользователя.
Например, таблица стилей XSLT может принимать на вход следующий XML-код:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
и этот 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>
и обработать их, чтобы получить следующий HTML-код для отображения в браузере: HTML
<body>
<p>Message: Hello World.</p>
</body>
В дополнение к инструкции обработки XSL, показанной в предыдущем примере, существует также JavaScript API XSLTProcessor , который можно использовать для обработки локальных XML-документов с локальными таблицами стилей XSLT.
История XSLT
XSLT was recommended by the World Wide Web Consortium (W3C) on November 16, 1999 , as a language for transforming XML documents into other formats, most commonly HTML for display in web browsers. Before the official 1.0 recommendation, Microsoft took an early initiative by shipping a proprietary implementation based on a W3C working draft in Internet Explorer 5.0 , released in March 1999. Following the official standard, Mozilla implemented native XSLT 1.0 support in Netscape 6 in late 2000. Other major browsers, including Safari, Opera, and later Chrome, also incorporated native XSLT 1.0 processors, making client-side XML-to-HTML transformations a viable web technology in the early 2000s.
The XSLT language itself continued to evolve, with the release of XSLT 2.0 in 2007 and XSLT 3.0 in 2017 , which introduced powerful features like regular expressions, improved data types, and the ability to process JSON. Browser support, however, stagnated. Today, all major web browser engines only provide native support for the original XSLT 1.0 from 1999. This lack of advancement, coupled with the rise of the use of JSON as a wire format, and JavaScript libraries and frameworks (like jQuery, React, and Vue.js) that offer more flexible and powerful DOM manipulation and templating, has led to a significant decline in the use of client-side XSLT. Its role within the web browser has been largely superseded by these JavaScript-based technologies.
Почему необходимо удалить XSLT?
The continued inclusion of XSLT 1.0 in web browsers presents a significant and unnecessary security risk. The underlying libraries that process these transformations, such as libxslt (used by Chromium browsers), are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. For example, security audits and bug trackers have repeatedly identified high-severity vulnerabilities in these parsers (eg, CVE-2025-7425 and CVE-2022-22834 , both in libxslt). Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk. Риски для безопасности, связанные с поддержанием этой уязвимой, устаревшей функциональности, значительно перевешивают ее ограниченную полезность в современных условиях.
Furthermore, the original purpose of client-side XSLT—transforming data into renderable HTML—has been superseded by safer, more ergonomic, and better-maintained JavaScript APIs. Modern web development relies on things like the Fetch API to retrieve data (typically JSON) and the DOMParser API to safely parse XML or HTML strings into a DOM structure within the browser's secure JavaScript sandbox. Frameworks like React, Vue, and Svelte then manage the rendering of this data efficiently and securely. This modern toolchain is actively developed, benefits from the massive security investment in JavaScript engines, and is what virtually all web developers use today. Indeed, only about 0.02% of web page loads today actually use XSLT at all, with less than 0.001% using XSLT processing instructions.
Это касается не только Chrome или Chromium: два других основных браузерных движка также поддерживают удаление XSLT из веб-платформы: WebKit и Gecko .
По этим причинам отказ от XSLT и его удаление уменьшают поверхность атаки браузера для всех пользователей, упрощают веб-платформу и позволяют сосредоточить инженерные ресурсы на обеспечении безопасности технологий, которые фактически обеспечивают работу современного веба, без практической потери возможностей для разработчиков.
Повышение безопасности анализа XML-файлов
Similar to the severe security issues in libxslt, severe security issues were recently reported against libxml2 which is used in Chromium for parsing, serialization and testing the well-formedness of XML. To address future security issues with XML parsing In Chromium we plan to phase out the usage of libxml2 and replace XML parsing with a memory-safe XML parsing library written in Rust. Importantly, we won't be removing XML from the browser; only XSLT is being considered for removal here. We intend to ensure that replacing libxml2 is entirely transparent to web developers.
XML + CSS не удаляется
Важно различать устаревание XSLT ( <?xml-stylesheet type="text/xsl" ... ?> ) и саму инструкцию обработки <?xml-stylesheet ... ?> , которая по-прежнему поддерживается при использовании с CSS. Вы по-прежнему можете использовать инструкцию обработки с type="text/css" для применения стандартных правил разметки и дизайна к вашим исходным данным, так же, как и с HTML. Например:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
Как осуществить миграцию
Существует несколько альтернативных путей миграции.
JSON
Для сайтов, полностью построенных на XML и XSL, нет универсального способа перехода. Варианты миграции включают перенос конвейера обработки XSLT на сторону сервера и отправку сгенерированного HTML клиенту, или миграцию серверных конечных точек XML API на JSON и выполнение рендеринга на стороне клиента с использованием JavaScript для преобразования JSON в HTML DOM и CSS.
XSLT на стороне клиента в JavaScript
Существует несколько клиентских (на основе JavaScript) библиотек XSLT, но самая крупная из них разработана компанией Saxonica ( подробную документацию по Saxonica можно посмотреть здесь). Ее реализация значительно превосходит стандарт XSLT 1.0 для веб-браузеров, обеспечивая полную поддержку новейшего стандарта v3.0 и, в конечном итоге, разрабатываемого стандарта v4.0 .
Полиэфирный наполнитель
Существует полифил, который позволяет существующему коду, зависящему от реализации XSLT 1.0 в веб-браузерах, продолжать функционировать, не используя при этом встроенные функции XSLT браузера. Полифил находится на GitHub .
Полифил содержит функциональную замену класса XSLTProcessor на основе WASM, поэтому существующий код JavaScript может продолжать работать как есть:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Полифил также предоставляет автоматическую вспомогательную функцию для простой замены XML-документов, использующих инструкции обработки XSLT:
Для оригинального файла demo.xml , подобного этому:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Для вызова полифилла и преобразования документа с использованием указанной таблицы стилей XSLT можно добавить всего одну строку:
<?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...
В этом случае новый элемент <script> загружает полифилл, который определяет тип XML-документа и инструкцию обработки XSLT и прозрачно загружает его, заменяя документ.
Расширение
Существует также расширение для Chrome , которое можно добавить в поддерживаемые браузеры. Оно будет применять один и тот же полифилл XSLT ко всем страницам в формате XML, содержащим инструкции обработки XSLT или вызовы XSLTProcessor. Это можно использовать в приложениях, где исходный XML или XSLT нельзя изменить, чтобы сохранить функциональность.
В частности, при отключении XSLT Chrome теперь отображает предупреждающий баннер, который ведет непосредственно на страницу поиска расширений, чтобы помочь пользователям найти нужное расширение:
Конкретные варианты использования
В ходе обсуждения стандартов HTML было выявлено несколько конкретных вариантов использования. В этом разделе подробно рассматривается каждый из них, чтобы предложить разработчикам, публикующим XML-ресурсы, использующие XSLT, дальнейшие пути развития.
RSS и Atom-каналы
Во многих существующих RSS или Atom-лентах XSLT используется для того, чтобы сделать необработанные XML-данные удобочитаемыми при просмотре непосредственно в браузере. Основное применение заключается в том, что когда пользователь случайно нажимает на ссылку RSS-ленты сайта, вместо того чтобы вставить эту ссылку в свой RSS-ридер, он получает отформатированный HTML-ответ, который он может прочитать, а не сам необработанный XML-код.
There are two paths forward for this use case. The "standard" HTML way to do this is to add <link rel="alternate" type="application/rss+xml"> to an (HTML-based) site, rather than adding an explicit (user-visible) <a href="something.xml"> that users might accidentally click. This solution allows RSS readers to find the feed if a user pastes in just the website URL, but it also allows human users to see the regular HTML content without getting confused by a link to an XML resource. This also follows the normal web paradigm that HTML is for humans and XML is for machines. Of course this doesn't solve the case where a user just "has" an RSS link from somewhere, and they paste it into their web browser (rather than their RSS reader).
When that solution isn't wanted, the polyfill offers another path. As mentioned previously, the RSS/Atom XML feed can be augmented with one line, <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script> , which will maintain the existing behavior of XSLT-based transformation to HTML. That shouldn't affect RSS reader's ability to continue parsing the XML, since the <script> is a direct child of the root element.
Вывод API для встроенных устройств
Некоторые коммерческие встраиваемые устройства измеряют или иным образом генерируют XML-данные для использования пользователями в локальной сети. Некоторые из этих устройств делают это, генерируя единый поток XML-данных, который с помощью XSLT преобразуется в удобочитаемый HTML-формат. Это позволяет просматривать API непосредственно в браузере без необходимости добавления дополнительного кода на устройстве или в браузере.
Since this is a very application specific use case, the shape of the solution might vary. For applications where the source code of the embedded device can be updated, any of the options described previously (JSON, Polyfill) could work. In particular, however, many such devices are difficult or impossible to update, for various reasons. In that case, the extension is likely the best option, since it allows client browsers to continue to read the data in exactly the same way, without modifying the device.
Ленивое создание шаблонов для веб-сайтов
Веб-разработчики иногда используют XSLT на стороне клиента для применения разметки представления к семантической разметке, функционируя как ленивый язык шаблонов, отдельный от экосистемы JavaScript.
There are two solutions to this more general problem. For an existing site built in this way, the easiest solution is likely just to add the polyfill to maintain existing functionality. Or perhaps perform the XSLT transformation on the server side, and serve the resulting HTML to the client, rather than the raw XML. The more long-term solution for such properties would be to migrate to a more modern JavaScript or JSON-based framework.
Если вы столкнетесь с конкретной проблемой в Chrome, связанной с устареванием XSLT, сообщите об ошибке здесь .
Как обнаружить использование XSLT
Как правило, устаревшие функции, такие как XSLT, можно обнаружить в вашем коде несколькими способами. В этом разделе описаны два из них.
API для создания отчетов
API для создания отчетов — это универсальный механизм для веб-приложений, позволяющий создавать отчеты о различных функциях и условиях платформы, включая устаревание функций. Для настройки отчетов об устаревании XSLT можно использовать следующий фрагмент кода:
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();
Посмотрите, как этот код работает, на CodePen .
Отчет о технологиях, устаревших в корпоративной среде
Администраторы предприятия могут использовать отчет об устаревших технологиях для автоматического сбора информации об использовании устаревших функций и предоставления отчетов в удобном для пользователя формате. Дополнительную информацию о включении этой функции см. в этой статье службы поддержки Google .