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%3DNeDgjbkMu4z_S%3DhV%2B8cszrDp-1_%2BUHWTy2j5ncV5NfemvzA%40mail.gmail.com.
