Thank you all! I appreciate it. I also appreciate the XSLT community, which has been working to migrate off this tech over the last year. I know this has been a monumental headache, and I’m so grateful to everyone who suffered through it.
Thanks, Mason On Wed, Sep 30, 2026 at 7:56 AM Daniel Bratell <[email protected]> wrote: > LGTM3 > > It is a bit strange sending the LGTM3 here when I was one of the people > that many, many years ago claimed that removal could not be done but I > guess persistence sometimes pays off. I'm impressed. > > /Daniel > On 2026-09-30 00:20, Mike Taylor wrote: > > LGTM2. +1 - thanks Mason for (nearly) achieving the near-impossible. Good > luck with the final steps! > On 9/29/26 2:32 p.m., Chris Harrelson wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8NAKebB6QQ%2BRJBe_ec1TAYu9OP%3Dii5Meq4Ne_2ZJfyVA%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/8eb9aa16-e8e9-43fa-bc68-deae1da19a27%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8eb9aa16-e8e9-43fa-bc68-deae1da19a27%40chromium.org?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/CAM%3DNeDjvJnsEMCSkXKGyhfWwDXLjcaVWr3ZobMFPDOte1Q67vA%40mail.gmail.com.
