LGTM1 Thanks for the diligent work to make this API removal as smooth as possible. I think the risk is low, and in addition security risks of not removing the API are high and growing.
On Tue, Sep 29, 2026, 1:59 PM Mason Freed <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgUxoR_bnwAW_6GAXRJ3tx401GKKdMee1E%3DkU%2BxPcVtQg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw8NAKebB6QQ%2BRJBe_ec1TAYu9OP%3Dii5Meq4Ne_2ZJfyVA%40mail.gmail.com.
