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
<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
<https://github.com/whatwg/html/issues/11523#issuecomment-3149788558>)
WebKit: Positive
(https://github.com/whatwg/html/issues/11523#issuecomment-3149280766
<https://github.com/whatwg/html/issues/11523#issuecomment-3149280766>)
Web developers: Negative
(https://github.com/whatwg/html/issues/11523#issuecomment-3150969971
<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
<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 <https://crbug.com/435623334>
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4709671889534976?gate=5156253931929600
<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>.
