Contact emails [email protected]
Explainer None Specification None Summary XSLT v1.0, which all browsers adhere to, was standardized in 1999. In the meantime, XSLT has evolved to v2.0 and v3.0, adding features, and growing apart from the old version frozen into browsers. This lack of advancement, coupled with the rise of JavaScript libraries and frameworks that offer more flexible and powerful DOM manipulation, has led to a significant decline in the use of client-side XSLT. Its role within the web browser has been largely superseded by JavaScript-based technologies such as JSON+React. Chromium uses the libxslt library to process these transformations, and libxslt was unmaintained <https://discourse.gnome.org/t/stepping-down-as-libxslt-maintainer/27615> for ~6 months of 2025. Libxslt is a complex, aging C codebase of the type notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. 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. For these reasons, Chromium would like to deprecate and remove XSLT. WHATWG decided to move XSLT deprecation to stage 3 <https://github.com/whatwg/html/issues/11523>, indicating broad agreement. Both other browser engines are also planning to deprecate XSLT. The proposed timeline for Chromium is to deprecate in M143, remove in M155 (except for Origin Trial and Enterprise Policy users), and discontinue the Origin Trial and Enterprise Policy in M164. See below for more details. Blink component Blink>XML <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EXML%22> Web Feature ID xslt <https://webstatus.dev/features/xslt> Motivation Security risks for all users outweigh the very small usage of this feature on the open web. Usage of the JS XSLTProcessor API <https://chromestatus.com/metrics/feature/timeline/popularity/79> is fairly volatile, registering somewhere between 0.01% and 0.1% of page loads, averaging around 0.05% over time. These numbers are above the typical 0.001% deprecation threshold. Again, we feel that the increased potential for breakage is balanced by the reduced security risk to 100% of Chromium users. And we are doing everything we can to mitigate this breakage and be proactive in reaching out to potentially affected sites and particularly libraries that might account for significant chunks of the overall usage. In addition, several sites we surveyed that use XSLTProcessor have feature detection code with fallbacks to JS libraries like Saxonica. Of the ~220 sites we've surveyed so far, roughly 72% of them are still functional even with XSLT disabled. The usage of declarative XSL Processing Instructions <https://chromestatus.com/metrics/feature/timeline/popularity/78> is significantly lower, around 0.001% for the last few years. This is at or below the safe deprecation threshold. Initial public proposal https://github.com/whatwg/html/issues/11523 TAG review None TAG review status Not applicable Risks Interoperability and Compatibility Removal of this feature constitutes a compat risk, since sites that use XSLT may stop working when the feature is removed. Mitigations include a very long deprecation window, a polyfill, lots of outreach, and both origin trials and enterprise policies to allow sites even more time to migrate. The polyfill <https://github.com/mfreed7/xslt_polyfill> is specifically built to mimic the existing behavior of Chrome as closely as possible. In most cases, it is a single-line drop-in fix for a lack of XSLT in the browser. According to my analysis, about 75% of sites that hit the use counter don't appear to be visibly broken. Of the 25% that do appear broken in some way (e.g. some components not rendering, or raw XML output instead of transformed HTML), 82% have their functionality restored by the addition of the single-line polyfill. Of the 18% that can't use the polyfill, the primary reason seems to be CORS restrictions, as detailed <https://github.com/mfreed7/xslt_polyfill/tree/main?tab=readme-ov-file#limitations> in the polyfill documentation. And even if site owners take no action, individual users can install the browser extension <https://github.com/mfreed7/xslt_extension>, which uses the polyfill, to get back full functionality. Gecko: Positive ( https://github.com/whatwg/html/issues/11523#issuecomment-3149788558) WebKit: Positive ( https://github.com/whatwg/html/issues/11523#issuecomment-3149280766) Web developers: Negative ( https://github.com/whatwg/html/issues/11523#issuecomment-3150969971) Existing users of XSLT are understandably negative on this removal, and have been very vocal about it on the standards issue and elsewhere. There are also mixed/positive reactions from some folks in the public discussions, many of whose participants seem to agree with the removal of XSLT from browsers. But the average/overall developer opinion (as measured by comments on public threads) is negative. Various public discussions: - https://news.ycombinator.com/item?id=44952185 - https://www.reddit.com/r/programming/comments/1mxdm22/xslt_removal_will_break_multiple_government_and/ - https://news.ycombinator.com/item?id=44987346 - https://news.ycombinator.com/item?id=44987552 - https://news.ycombinator.com/item?id=44987239 - https://news.ycombinator.com/item?id=44909599 Other signals: Activation See above - the polyfill and extension will ease the migration burden. Security This removal constitutes a big win for security, in that it removes a highly-vulnerable external library from Chromium. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? In the same way that this poses a compat risk on the open web, it poses a risk for WebView applications. Deprecation/Removal Plan The tentative deprecation/removal plan would be as follows: - M142 (Oct 28, 2025): Early warning console messages added to Chrome. - M143 (Dec 2, 2025): Official deprecation of the API - deprecation warning messages begin to show in the console and in lighthouse. - M148 (March 10, 2026 Canary): Canary, Dev, and Beta releases begin disabling XSLT by default, as an early-warning. - M152 (Aug 25, 2026): Origin Trial and Enterprise Policy go live for testing. These allow sites and enterprises to continue using features past the removal date. - M155 (Nov 17, 2026): XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants. - M164 (Aug 17, 2027): Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users. Debuggability None Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes These tests verify the functionality of XSLT. They will need to be changed/removed: https://wpt.fyi/results/dom/xslt Flag name on about://flags XSLT Finch feature name XSLT Requires code in //chrome? False Tracking bug https://crbug.com/435623334 Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4709671889534976?gate=5156253931929600 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgFVe5xg6usiWHy7ko7X93D2094yf%3DK%3Db7nfD-GJjunkQ%40mail.gmail.com.
