Standard template below. But note that this is a request for a deprecation trial <https://developer.chrome.com/docs/web-platform/chrome-deprecation#:~:text=default%20from%20Chrome.-,Deprecation%20trial,-This%20is%20a>, starting M152 and going until M175. That's inline with the posted timeline <https://developer.chrome.com/docs/web-platform/deprecating-xslt#timeline_for_chrome>, allowing affected sites plenty of extra time to migrate away from XSLT, in case they cannot migrate before the feature is disabled by default in M158 (Nov, 2026). Also note that this deprecation trial is being requested several milestones early to allow plenty of time to test before the feature is disabled.
----- *Contact emails* [email protected] *Explainer* *No information provided* *Specification* *No information provided* *Design docs* *No information provided* https://github.com/whatwg/html/issues/11523 *Summary* [XSLT v1.0](https://www.w3.org/TR/xslt-10/), 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 and 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 (along with both other browser engines) plans to deprecate and remove XSLT from the web platform. For more details, see this [Chrome for Developers article]( https://developer.chrome.com/docs/web-platform/deprecating-xslt). *Blink component* Blink>XML <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EXML%22> *Web Feature ID* xslt <https://webstatus.dev/features/xslt> *TAG review* *No information provided* *TAG review status* Not applicable *Goals for experimentation* 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 (OT) and Enterprise Policy (EP) go live for testing. These allow sites and enterprises to continue using features past the removal date. - M158 (Nov 17, 2026): XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants. - M176 (Aug 17, 2027): Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users. *Risks* *Interoperability and Compatibility* Removal of this feature constitutes a compat risk, since sites that use XSLT will 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 polyfill. Of the 18% that can't use the polyfill, the primary reason seems to be CORS restrictions, as detailed 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, who 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. *Ongoing technical constraints* *No information provided* *Debuggability* *No information provided* *Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* Yes *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* Origin trial desktop first 152 Origin trial desktop last 175 DevTrial on desktop 143 Origin trial Android first 152 Origin trial Android last 175 DevTrial on Android 143 Origin trial WebView first 152 Origin trial WebView last 175 Rollout step 1 176 Rollout step 2 143 Rollout step 3 152 Rollout step 4 158 *Link to entry on the Chrome Platform Status* https://chromestatus.com/feature/4709671889534976?gate=5148216907661312 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%3DNeDhO%3D2mNq8QyzU5Ah9z8FR6pO9tct9G_prKD6bdtAE7cwA%40mail.gmail.com.
