I'm following up on this intent, since the branch point for M157 is coming up on Oct 12, after which Canary will be M158. The plan <https://chromestatus.com/feature/4709671889534976> is to disable XSLT by default starting in M158, so I have flipped the API owners review bit for this removal. Here are some updates related to this deprecation:
- XSLT was disabled by default in all pre-stable channels starting in M145 (154 for WebView). - A user-visible warning (with significant community feedback and fixes) is present on XSLT-transformed pages (and XSLTProcessor-transformed documents) since M156 (just for the last two milestones before removal). - The Enterprise Policy has been available since M146 (allowing both opt-back-in, and early-opt-out). This deprecation was also published in the enterprise release notes starting Oct, 2025. - The Deprecation Trial has been available since M152 (allowing only opt-back-in). - Lots of great feedback <https://github.com/mfreed7/xslt_polyfill/issues?q=is%3Aissue> and bug fixes <https://github.com/mfreed7/xslt_polyfill/commits/main/> on the polyfill and Chrome extension. Both seem to be rather functional across most use cases. - When XSLT is disabled in the browser, a user-visible warning links directly to an extension search, where the polyfill extension <https://chromewebstore.google.com/detail/xslt-polyfill/hlahhpnhgficldhfioiafojgdhcppklm> shows up. So in still-broken cases, users have recourse. - CAP Alerts (emergency alerts) are exempted from the initial default-removal, because they can't use deprecation trials. They will have a user-visible warning banner, and will be disabled in the final removal milestone of M176. - The HTML standard and DOM standard now mark XSLT as "do not use" <https://html.spec.whatwg.org/multipage/infrastructure.html#interactions-with-xpath-and-xslt>, and CanIUse says "Discouraged" <https://caniuse.com/wf-xslt>. - I've had lots of conversations (public and private) with folks who are migrating away from the browser-native feature. All have been resolved, at least as far as I can tell. - The use counters are still roughly flat. This is not a surprise - deprecations usually make counters go up, in my experience. In my view, we should proceed with the removal now, keeping to the published schedule. I'm requesting API owner approval to disable XSLT by default in M158. Thanks, Mason On Thu, Sep 3, 2026 at 11:12 AM Mason Freed <[email protected]> wrote: > > On Thu, Sep 3, 2026 at 5:57 AM Khristine Belandres <[email protected]> > wrote: > >> Given the 2-week release starting M152 (Aug 25, 2027), is the plan also >> changing specifically for M155 and M164? Do we follow the dates or the >> release version? >> >> - 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. >> > > Thanks for highlighting that! When the 2 week cycle was announced, I > updated the chromestatus entry > <https://chromestatus.com/feature/4709671889534976> accordingly (look for > either "Experiment goals" or "Rollout steps" on that page) and the blog > post timeline > <https://developer.chrome.com/docs/web-platform/deprecating-xslt#timeline_for_chrome>. > The new milestones are M158 and M176, respectively; they follow the > original dates, not the old milestone numbers. I suppose I should have > emailed this thread, also! > > Thanks, > Mason > > > >> On Saturday, October 25, 2025 at 5:58:49 AM UTC+8 Mason Freed wrote: >> >>> 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%3DNeDgUxoR_bnwAW_6GAXRJ3tx401GKKdMee1E%3DkU%2BxPcVtQg%40mail.gmail.com.
