Разработчики браузера Chromium приняли решение отказаться от поддержки языка XSLT (Extensible Stylesheet Language Transformations) и прекратить использование библиотек libxslt и libxml2. Это решение обусловлено стремлением сократить потенциальную поверхность атак и повысить безопасность браузера. В частности, библиотека libxslt регулярно становится источником уязвимостей, таких как CVE-2025-7425 и CVE-2022-22834, а также имеет проблемы с сопровождением — в определённые периоды она вовсе не получала обновлений безопасности.
По мнению Google, поддержка XSLT 1.0 в современных браузерах уже нецелесообразна. Использование XSLT на стороне клиента в реальных веб-приложениях крайне невелико: статистика показывает, что лишь 0.02% всех загруженных страниц содержат XSLT, а активное использование инструкций обработки — всего 0.001%. Такие низкие показатели делают поддержку технологии не только избыточной, но и потенциально опасной.
Кроме XSLT, из Chromium также будет удалена библиотека libxml2, которая используется для разбора и сериализации XML-документов. Поддержка XML в браузере сохранится, но будет переведена на новую реализацию, написанную на языке Rust. Этот шаг направлен на улучшение безопасности и стабильности, ведь Rust позволяет избежать множества типичных ошибок управления памятью, характерных для C/C++-библиотек, таких как libxml2.
Удаление XSLT затронет такие возможности, как API XSLTProcessor и обработку XML-стилей через инструкции вида . Полностью поддержка этих функций будет прекращена в версии Chrome 155, релиз которой намечен на 17 ноября 2026 года. Однако подготовка начнётся заранее: в Chrome 143 (2 декабря 2025 года) разработчики начнут получать предупреждения в консоли о предстоящем устаревании API XSLTProcessor, а в Chrome 148 (весна 2026 года) XSLT будет отключена по умолчанию в версиях Canary, Dev и Beta.
Взамен разработчикам предлагается переносить XSLT-преобразования на серверную сторону. Это означает, что XML-документы должны преобразовываться в HTML до отправки браузеру. Также рекомендуется использование JSON в качестве формата обмена данными между клиентом и сервером, с последующим преобразованием информации в HTML или другие форматы с помощью JavaScript и DOM API.
Для тех, кто всё же нуждается в XSLT в клиентских сценариях, возможны обходные решения. Например, существуют JavaScript-библиотеки, такие как Saxonica, реализующие XSLT в браузере. Также обсуждаются polyfill-решения на базе WebAssembly, которые могут эмулировать работу XSLTProcessor, обеспечивая совместимость со старым кодом. Возможна даже разработка браузерных расширений, автоматически внедряющих такие polyfill в XML-документы.
Интересно, что отказ от XSLT — не уникальное решение Google. Разработчики других браузеров, включая Firefox и WebKit (на базе которого работает Safari), также рассматривают возможность исключения XSLT из своих движков. Это говорит о тенденции к унификации, безопасности и отказу от устаревших технологий, которые не соответствуют современным требованиям веб-разработки.
Несмотря на это, следует признать, что XSLT исторически играл важную роль в трансформации XML-данных. Особенно в корпоративных системах, где активно применялись SOAP, WSDL и XSD. Однако с ростом популярности JSON и REST-архитектуры, эти технологии постепенно уступили место более простым и гибким решениям.
JSON, хотя и обладает меньшими возможностями по строгой валидации данных по сравнению с XML и XSD, стал де-факто стандартом для обмена данными в вебе. Попытки стандартизировать JSON-схемы, такие как JSON Schema, всё ещё находятся на стадии черновиков, однако этого уже достаточно для нужд большинства разработчиков. При этом применение строгих XML-стандартов по-прежнему актуально в B2B-среде, где важна совместимость между различными поставщиками программного обеспечения.
Если же кто-то продолжает использовать XML и XSLT в своей архитектуре — например, в закрытых системах или специализированных бизнес-приложениях — им придётся адаптироваться. Один из возможных путей — интеграция XSLT-движков в WebAssembly, что позволит запускать преобразования прямо в браузере без использования устаревших и небезопасных нативных библиотек.
Есть и другой подход: полностью отказаться от клиентской логики на основе XML, заменив её универсальными HTML-шаблонизаторами или фреймворками JavaScript, такими как React, Vue или Svelte. Они предлагают гораздо более гибкие, масштабируемые и безопасные решения для отображения данных на клиенте.
Таким образом, отказ от XSLT в Chromium отражает общее направление эволюции веба: переход к более простым, безопасным и широко поддерживаемым технологиям. Поддержка устаревших спецификаций, малораспространённых и уязвимых, больше не оправдана в условиях, когда есть современные альтернативы, обеспечивающие такую же или лучшую функциональность с меньшими рисками.
Разработчикам, чьи проекты всё ещё зависят от XSLT, стоит начать адаптацию уже сейчас, чтобы избежать проблем в будущем. Новые версии Chromium уже в ближайшие годы начнут поэтапно отключать устаревшие функции, и лучше заранее подготовиться к изменениям в архитектуре приложений.
