Should the web platform adopt XSLT 3.0?

What is the issue with the HTML Standard?

Background

This is a follow-up to #11523. That issue raises concerns regarding security issues, code maintainability, and the complexity of aging browser code currently used for rendering XML with XSLT stylesheets. I highly recommend reading through that issue first as it includes a good background of XSLT on the web as well as the specific concerns that may lead to deprecating XSLT as the most prudent option for browser vendors.

As a reminder, please read the whatwg Code of Conduct. This issue is intended to be a discussion of alternatives to deprecations and how the concerns raised in #11523 may be handled to mitigate the risks for both browser maintainers and users. Please stay on topic here by discussing the pros and cons of XSLT v3.0 support, alternatives, etc. Discussions related to assumed motivations, specific browser vendors, etc. aren't relevant here and will likely just result in the issue being locked, preventing us from having the important discussion in public here.

What is the issue with the HTML Standard?

The XSLT 1.0 specification was originally standardized in 1999. Though the W3C has subsequently defined 2.0 and 3.0 specifications for XSLT, most browsers today never added support beyond v1.0. In addition, cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues dating back over two decades with no fix in sight. I raise longstanding issues in general as a challenge related to the concerns of maintainability and relatively little use of XSLT 1.0 today, not as a concern over prioritization or resource allocation by browser vendors.

The question of use of XSLT today, raised in #11523, raises an interesting question. Is the low usage statistics of XSLT today an indication of the usefulness of the specification in today's web, or an indication of the challenges of dealing with v1.0 limitations and bugs? Deprecating XSLT entirely assumes that the issue related to use relies only on XSLT itself and that use would go effectively unchanged if the improvements from v2.0 and v3.0 were available in browsers. Anecdotally I can say that I have run into blocking issues with v1.0 itself; I built a blogging CMS as a hobby project that was designed to lean entirely on XSLT to render CMS users' RSS feeds to complete, customizable websites. Between vendor-specific XSLT bugs and the limitations of a now 25 year old spec, I found that I would only be able to build the CMS with a more recent version of the XSLT specification.

Alternatives to deprecation

I don't intend to prescribe a solution here! Instead, these open questions (and others I missed) are important when weighing the relative merits with regards to deprecating XSLT entirely.

Are there external libraries that browsers could adopt in order to gain v3.0 support without building and maintaining the specification in house?
Are there security concerns relevant to v3.0, or are the concerns limited to the v1.0 specification and current implementations?
Is there an approach that would allow browser vendors to use a single implementation for XSLT, combining efforts to reduce cost on each vendor?

One consideration that unfortunately no one can add to the other thread:

Or perform the XSLT transformation on the server side, and serve the resulting HTML to the client. The more long-term solution would be to migrate to a more modern JS/JSON-based framework.

The more "modern" solutions proposed all greatly raise the barrier to entry on the web. The cool thing about XSLT is that it provides a fully static way to add templates to a website (a need everyone immediately comes across once they have more than 2-3 web pages) that you can work your way into piecemeal as you discover your needs without needing build steps or API servers or anything like that. I'm guessing people that program professionally forget that dealing with things like npm, webpack, etc. are way more difficult than wrapping your text in some markup, adding some styles, realizing that you want to extract those out into a stylesheet so you can use them on multiple pages, and eventually coming to understand that you really want to template the whole thing. The old web standards provide a very natural onramp and let you go only as far as you need at any given time. Getting onto the programming language treadmill also pushes security maintenance burden onto authors (who now need to keep on top of regularly updating their frameworks, following the treadmill of paradigm shifts, etc. when they just wanted to make a web site).

The suggestion that someone who wants to make a website should go learn a programming language & frameworks or how to set up a server processing pipeline seems to me to hammer home to idea that individuals are simply no longer relevant to "the web platform". I suppose the writing was on the wall when we gave up on the idea of WYSIWYG editors (remember when Seamonkey had that built right in?) and started normalizing the idea that even simple, completely static web pages like blogs require programming/are not something for the common person to be able to make, but it's still sad.

Is the low usage statistics of XSLT today an indication of the usefulness of the specification in today's web, or an indication of the challenges of dealing with v1.0 limitations and bugs?

Another factor to consider is whether people are aware of this technology in the first place, and what it is capable of. Personally, when I learned that I can style my RSS feeds to make it user-friendly and include a helpful message at the top explaining what a feed is and how the user can subscribe to it, I immediately applied it to my RSS feed.

As of this issue receiving a lot of attention, I've started informing my fellow developers about XSLT and encouraging them to apply it to their own RSS feeds.

I do agree that something needs to change at least. I set up an XSLT stylesheet for my sitemap last year and it was spectacularly frustrating that there was no clear information anywhere on what features were actually supported by the browsers and the complete lack of feedback when I used an unsupported feature. Sometimes it just hung my entire Firefox process which was unsettling to say the least.
I'm sure at least some of the lack of adoption is caused by developers assuming the entire technology is broken and giving up.

If browser vendors do not have enough resources independently to maintain their XSLT implementations, perhaps resources could be pooled into a single pdf.js style project that could be adopted by all browsers, providing a uniform and consistent experience? Being written in JS would presumably make it easier to provide active feedback to the developer when they make mistakes too. 🙂

I know XSLT has fallen out of favor over the past 20 years, and most developers don’t really care about it anymore. But when it’s used with purpose and skill, it’s incredibly powerful. I’ve been working with XSLT since I first discovered it about ten years ago, and it has become my language of choice for building content-driven websites. I’m sure I’m not entirely alone in this, but sometimes it feels like there are, like, maybe three of us who use XSLT as consistently as I do. And that’s a shame.

XSLT could replace many of the technologies that have been bolted onto the Web platform over the years. With proper browser support for XSLT 3.0 and just a little push in public awareness, it could be a game changer.

There are so many advantages to using XSLT on the Web, but the developer community simply doesn’t know about them. If they did, we might already have full XSLT 3.0 support in browsers. Let’s try to make that happen, then!

One concern I have with an alternative approach leveraging either a polyfill or a browser extension is that either approach lose some of the core features of XSLT. With XSLT built into browsers, developers have access to a client-side templating engine that is "closer to the metal" and will work when JS is disabled or unavailable in the browser. Unless I'm mistaken, polyfills and extensions wouldn't work in that scenario and there would be a noticeable performance hit compared to XSLT rendering.

I'm interested to hear more from engineers with deeper experience in the existing XSLT implementations.

Given the age and general state of the current v1.0 implementations, is it reasonable to assume a v3.0 implementation would be a complete rewrite?

Ignoring resource availability and current priorities, what would a realistic estimate be for the effort it would take to implement and is there an avenue in which one implementation could be used across multiple browsers to spread the effort?

One concern with removing XSLT from the web platform entirely is that it means it that not only will the v1.0 implementations be removed, we will likely never see them replaced with the modern specifications. We do want WHATWG to realistically reflect what browser vendors have implemented or are expecting to implement, if there truly is no interest in supporting XSLT in the future then so be it I suppose. That is a different conversation compared to security and maintainability of the current implementation, but browser vendors only have so much bandwidth and that's totally reasonable and WHATWG should reflect that if there's vendor consensus.

One area where I think the lack of XSLT support may be more glaring in the future is with the continued growth of LLMs. If the MCP spec isn't broadly adopted, or if it runs into challenges during adoption, web developers may need a different solution for providing proper REST APIs to LLMs. XML has gone out of favor, but it is a great fit for that scenario. I could see a future where we end up developing one semantic REST API providing web page/app state as XML; LLMs interact directly with that gaining what they need from semantic markup and browsers render the exact same state via XSLT stylesheets. One XML API can serve both use cases, and it does seem like the LLM use case will only grow to a larger piece of the pie in the near future.

@mfreed7

cc @mfreed7

On disable-output-escaping="yes", this is problematic to support because it requires serialization and parsing of the transformed content. For efficiency in a client-side setting, you want a DOM-to-DOM transformation, which is what Gecko does. Possibly, adopting a third-party library that supports XSLT 3.0 would mean switching to a serialize-parse model (and thus theoretically regress performance).

Are there security concerns relevant to v3.0, or are the concerns limited to the v1.0 specification and current implementations?

I think there's inherent XSS risk with supporting XSLT regardless of version, because the transformed content can execute script and the expectation may be that e.g. RSS is safe.

I think there are also non-security arguments against client-side XSLT, e.g. lack of incremental rendering.

As a reminder, please read the whatwg Code of Conduct. This issue is intended to be a discussion of alternatives to deprecations and how the concerns raised in #11523 may be handled to mitigate the risks for both browser maintainers and users. Please stay on topic here by discussing the pros and cons of XSLT v3.0 support, alternatives, etc. Discussions related to assumed motivations, specific browser vendors, etc. aren't relevant here and will likely just result in the issue being locked, preventing us from having the important discussion in public here.

I don't have a more detailed comment on this issue right now, but I wanted to explicitly say thank you for this portion of your comment, and for the general tone you've created here. It is appreciated.

My reasons for mourning the loss of XSLT:

Many design web component libraries use markup that is modeled after built-in elements, like the table, ul/li, etc. These web components are beautiful, but the problem is that it's really difficult to make the light DOM children look the same while waiting for the component to download. With XSLT and just a few lines of very clear instructions, one can let the server be "design library neutral" and ship native table elements, which, with a little styling, can look close to what the design library provides, without the bells and whistles. Then, when the library has downloaded, apply the XSLT and replace the table with the web components. Obviously having to download a monstrous polyfill would defeat the purpose.
There are scenarios where xslt 3's streaming support would shine, like dynamically building a table of contents as the actual content streams in dynamically.
If it could be used in the service worker layer, it could allow bringing in content from third party web sites, and filter out content in an elegant way. I have another proposal that could do this, but it's just been sitting there gathering dust.

Why don't the browser vendors do this: Say how much it would cost to incorporate a library, initially and per year, and see if kickstarter can raise the funds? I think that would be a much better look, even if sufficient funds aren't raised.

@zcorpan

@zcorpan and @mfreed7 thank you both for jumping in here!

Possibly, adopting a third-party library that supports XSLT 3.0 would mean switching to a serialize-parse model (and thus theoretically regress performance).

Alternatives to in-browser XSLT support would rely on polyfills or browser extensions. Though adopting third-party libraries would likely mean a performance regression compared to what we have today, would it likely still outperform a polyfill or extension approach?

I think there's inherent XSS risk with supporting XSLT regardless of version, because the transformed content can execute script and the expectation may be that e.g. RSS is safe.

This concern is particularly interesting to me. I've viewed the XSS risk similar to that of using innerHTML DOM APIs or dangerouslySetInnerHTML in react. Are there situations where XSLT actually poses a more fundamental risk than using innerHTML and related wrappers over that API (apologies if I missed examples already given elsewhere in ongoing discussions)? If so, that seems like a very important example for why deprecating XSLT is more important than updating to the latest specs.

The new Polish e-Invoice will also use the XML format (many government documents do), and with XSLT we can have one community-or-government-made template which everyone could integrate regardless of used technology. It'd also be great if the web browser was able to display just the XML file without any need for additional UI frameworks, it'd reduce the friction to basically zero.

I've learned about XSLT relatively recently, precisely because of this invoice change.. seeing this I was wondering why wasn't it more popular and why so few people were talking about it, but while trying to modify these templates I quickly noticed the limitations of XSLT 1.0 which doesn't even support user functions.
But many don't even know about XSLT at all, especially new developers who might feel overwhelmed by today's complicated web technologies.. the article "XSLT – Native, zero-config build system for the Web" got popular only recently, perhaps because many just didn't know that even existed and was already supported by web browsers?

So I think there's a good opportunity to reduce the barrier to entry for the web by improving XSLT, I genuinely believe this technology has more potential, we just need to give it a proper try!

I think there's inherent XSS risk with supporting XSLT regardless of version, because the transformed content can execute script and the expectation may be that e.g. RSS is safe.

Oh, it definitely shouldn't be able to execute any JS code..

Regarding implementation details, builtin support via JS/WASM should alleviate security concerns. But for extensions, it should at least be possible to install it with one click instead of being redirected to web store with spammy third-party extensions..

"closer to the metal" and will work when JS is disabled or unavailable in the browser. Unless I'm mistaken, polyfills and extensions wouldn't work in that scenario and there would be a noticeable performance hit compared to XSLT rendering.

I'm very curious about the impact of polyfills and extensions when the data is XML coming from an embedded device and being transformed by XSLT for a web based control interface or reporting dashboard (which can do things like localisation, text translation for the interface, data visualisations), or to integrate with other systems (like the XML-based APIs used in network devices or medical monitoring systems that get transformed with XSLT into more user friendly formats like HTML or JSON for the systems they integrate with); my understanding is a polyfill isn't going to fit well there and it can't be done serverside when the server is a microcontroller running a web server. Moving to XSLT 3 could unlock a lot more richness for how the data from embedded systems could be used and even a small perf hit from that would presumably be better than the whole data handling having to be reimplented in Java? And like enterprise usage, that also wouldn't show in web stats...

I'm very curious about the impact of polyfills and extensions when the data is XML coming from an embedded device and being transformed by XSLT for a web based control interface or reporting dashboard

If you can change the Content-Type header and serve that as text/html, you might be able to use a trick inserting this below the xml-stylesheet directive:

<?js-stylesheet /><script src="https://example.com/style.js"></script><!--?><!-- -->

and then that style.js could generate the page with high flexibility, while the XML file remains valid and can still contain a normal XSLT stylesheet..

But I believe we should go the opposite way - instead of legitimizing the use of JS for such simple cases, we should discourage it by supporting powerful, more user-friendly alternatives such as XSLT 3.0.
JS can do too much and it's difficult for the user to inspect it to ensure only code that serves their interest is allowed to execute, plus it can even interfere with such measures.

Though adopting third-party libraries would likely mean a performance regression compared to what we have today, would it likely still outperform a polyfill or extension approach?

I think the biggest difference in performance is DOM-to-DOM vs. serialize-transform-parse strategy. The former is better for performance, but the latter is possible to sandbox and therefore likely better for security.

For XSS specifically, it's maybe about the same as innerHTML, however there are other classes of security bugs reported for XSLT that don't apply to innerHTML, e.g.: reading local files, various UAF bugs, bypassing CSP, etc.

Since XSLT 3.0 has more features than 1.0, in theory it means more attack surface. Some classes of bugs could be addressed by using an implementation written in a memory-safe language + sandboxing, though.

The phenomenon of XSLT implementations getting stuck at XSLT 1.0 is broader than just browsers:

Xalan is at XSLT 1.0. According to Wikipedia, "Microsoft provides two XSLT processors (both XSLT 1.0 only)."

Adding XSLT 3.0 support either in the context of libxslt (WebKit and Chromium) or Transformiix (Gecko) doesn't make sense from the point of view of the current technical state of libxslt or Transformiix or as a matter of the amount of effort needed vs. the benefit and considering the opportunity cost of what else could be accomplished in Web browser development with that amount of effort.

Which makes the question

Are there external libraries that browsers could adopt in order to gain v3.0 support without building and maintaining the specification in house?

relevant.

Setting aside for the moment the question of whether the benefit would be worth the integration effort, let's look at the other requirements:

First there's the question of level of integration vs. performance. Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance: The XSLT engine doesn't operate on the browser DOM but the XSLT engine and the rest of the browser communicate via XML as serialized as text. The Gecko approach gives rise to opportunities for security bugs (due to both XSLT and JS having access to the same DOM) that the inherently-bad-for-performance XSLT integration architecture that WebKit and Chromium use protects from.

So perhaps worse is better and we don't even need to constrain the search for an external library to one that could operate on an externally-provided XML tree (i.e. the browser DOM)!

But there are still real constraints left (list possibly not exhaustive!):

The external library needs to be under an Open Source license (and likely one that doesn't have provisions that would make the exact manner of integration a license matter in addition to being a technical matter) and the preferred form for making modifications needs to actually be available.
The external library needs to implement enough XSLT 1.0 and EXSLT compatibility that existing Web content written for libxslt and Tranformiix keeps working.
The external library needs to use a programming language that fits the memory-safety requirements and engineering practices of Web browsers. (That is, even implementation in a safe language isn't OK if browsers don't otherwise contain code in that particular safe language and adding the capability to use code in that language would be involve high up front and ongoing cost.)

I'm not aware of any existing XSLT 3.0 implementation that satisfies those three rather basic constraints.

(Typically Xee is suggested as the solution. At this time, it fails the second constraint. I can't speak for Safari, but it might also fail the third constraint for Safari.)

The phenomenon of XSLT
implementations getting stuck at XSLT 1.0 is broader than just browsers:

To expand on this a bit if you look at any runtime with XSLT built-in: e.g. Java, PHP, .net they're all limited to XSLT 1.0 (happy to be corrected)

PHP for example is using libxslt the same library as chromium and WebKit.

Other third-party libraries that are used for other languages like python's lxml also don't support more than libxslt 1.0 (they're also based on libxslt).

If there was an obvious convergence on a specific V2 or V3 implementation then it might make more sense but if nothing else has made the move to integrate a newer version it probably presents more work for browsers if they were to be the first (and possibly only) to do that.

From my point of view, the large backlash wasn't the removal of XSLT per se, but the removal of built-in browser support. If browser makers want to remove libxml2/libxslt and replace it with an internal JavaScript-based "extension", that's fine because it won't break existing websites. The "beauty" of XSLT was that is "just worked" with no work on the author's part. IMHO, that's also how any "XSLT 3+" support should work.

@colejohnson66

@colejohnson66 "just works" and "JavaScript-based" aren't necessarily synonyms; without relitigating many previous threads, it's worth mentioning that the number of what you might consider non-technical users who disable JavaScript in the browser is probably higher than you'd expect. Over at AskWoody we recently had to add Cloudflare anti-AI bot protection and immediately discovered how many readers were using NoScript to stop sites from running any JavaScript, so if XSLT support (1 or 3) depends on internal JavaScript, it would be important to test whether users who would previously have had XSLT sites "just work" would see errors/lost functionality and whether tools like NoScript would need to add something to allow the internal 'extension' to work.

@marypcbuk

@marypcbuk The supposed reasoning for ditching XSLT (version 1) is because of libxml2 and libxslt being a horrific, unmaintainable, CVE-laden mess. So, if thrown to JavaScript (or WASM), those problems go away. So, my thought was that the JavaScript XSLT processor "extension" would be treated more like an internal detail - JavaScript under the hood, but not actually an extension. Same as pdf.js. Meaning NoScript (and the like) don't affect it.

I think this is of interest for the discussion here and provides relevant context, particularly about the implementation status of XSLT 3.0:
w3ctag/obsoletion#10

It certainly seems like it would be far more effort collectively to ask every person with an RSS feed to find some other way of displaying it nicely than it would for browser implementors to link and XSLT library and run a web page through it before display.

TBH it feels like if browsers cared about RSS they could add proper built in rendering for atom feeds and sitemaps and 90% of people who object to the killing of XSLT (including me) would fade into the background appeased 🙃

But on the other hand, if you look at how they've treated RSS over the years, I don't think they do care and will be unswayed by any arguments involving it.

If they bundled an RSS reader with it, I could understand that and get on board, but it would be easier for them and better for users to just leave it as it is. We can already render RSS in a pretty and extensible format, which also happens to be good for other kinds of structured data as well. There are safe libraries written in Rust for processing XSLT, and the C libraries could be compiled to WASM and sandboxed that way.

The only argument for removing XSLT is developer laziness. I'll admit I'm not an expert in browser development, but checking for an XML tag and running the page through a library function if it's sounds like the simplest and lowest maintenance solution here. I don't see how swapping from one library to another could be more than a few days work given there is only really a single call involved.

I believe talking to https://github.com/LadybirdBrowser/ladybird may prove fruitful.

I finally wrote down a concrete proposal that has been in my head since this all went down last year. Moving it forward since the deprecation notices are now up in Chrome. I'm calling it SWeT, for Standard Web Templates. The idea would be to revitalize XSLT ≥3.0 with a compact syntax (kind of like how RelaxNG has one that is isomorphic to the XML). I propose defining HTML DOM semantics for XPath, as well as an initialization hook for HTML analogous to the xml-stylesheet processing instruction. SWeT code itself would transpile to vanilla XSLT.

As for an implementation, there is also https://supso.org/projects/sup-xml/docs/guides/xslt. As far as I can tell, it is far ahead of xee or xrust, at least for XSLT 2.

Ah. I can see the license on that one being an issue.

It should not. And if will, it will poison as platform and the idea of ability to evilve the browser.
Why. XSLT promotes the concern separation via namesspace and breaks the context ownership. The both are essential parts of ability to safely expand as templating and as app engine. XSLT is not a template render API. Its stack include the module loading, document handling, hiding the source of change, etc. By introduction of immature solusion,it would force the industry to find and solve each aspect of SDLC for mature framework. It has happen with XSLT 1, and with V3 will mizerably fail too. WIth generation literrally hating it.

I do have the answer for that, it resides in full SDLC of web apps addressed. And, not surprize it would have XSLT 3 just as little part of it. Most likely would not be picked as its syntax comparing to alternatives is way less attractive for DX either manually or by AI.

@zcorpan

@zcorpan wrote:

I think there are also non-security arguments against client-side XSLT,
e.g. lack of incremental rendering.

XSLT 3.0 Streaming mode allows incremental rendering.
However, stylesheet code should be written in a way that enables streaming.

The XSLT in order to be useful in UI should be exposed as part of HTML itself as templating syntax. I.e. the XSLT source from page DOM tree parsed by browser itself and without the need for additional copy and transformation.
The code bellow would be efficient only when there is no need as for additional parsing as to copy of template. HTML parser meant to be streaamed and multithreaded and capable of accepting various content types. In order to be extendable, the schema based parser would be needed ( as opposite to algorighm based now). Means the changes should trouch

content types syntax driven by schema
parser based on schema, aware of content type changes.
parser streaming and multithreading
html changed from single schema+2 hardcoded ones to flexible schema-defined. No hardcoded tag set as HTML+SVG+MathML
defalut namespace mix introduced as public contract.

Which means XSLT alone should not be even introduced without the stack which comes with it.

@sashafirsov

@sashafirsov wrote:

Which means XSLT alone should not be even introduced without the stack which comes with it.

What do you see as as a feasible evolutionary path to such a stack? (if any)

Navigation Menu

Repository navigation

Should the web platform adopt XSLT 3.0? #11578

What is the issue with the HTML Standard?

Background

What is the issue with the HTML Standard?

Alternatives to deprecation

45 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Should the web platform adopt XSLT 3.0? #11578

Description

What is the issue with the HTML Standard?

Background

What is the issue with the HTML Standard?

Alternatives to deprecation

Activity

ndriscoll commented on Aug 19, 2025

Chailotl commented on Aug 19, 2025

Lexicality commented on Aug 19, 2025

emmacharp commented on Aug 20, 2025

tony-sull commented on Aug 20, 2025

zcorpan commented on Aug 20, 2025

mfreed7 commented on Aug 20, 2025

bahrus commented on Aug 20, 2025

tony-sull commented on Aug 21, 2025

zb3 commented on Aug 21, 2025

marypcbuk commented on Aug 21, 2025

zb3 commented on Aug 21, 2025

zcorpan commented on Aug 22, 2025

hsivonen commented on Aug 22, 2025

lukewarlow commented on Aug 22, 2025

45 remaining items

colejohnson66 commented on Oct 6, 2025

marypcbuk commented on Oct 6, 2025

colejohnson66 commented on Oct 6, 2025

hannob commented on Oct 28, 2025

jack-faller commented on Nov 10, 2025

Lexicality commented on Nov 10, 2025

jack-faller commented on Nov 10, 2025

alethkit commented on Jan 8, 2026

doriantaylor commented on Oct 2, 2026

martin-honnen commented on Oct 2, 2026

doriantaylor commented on Oct 2, 2026

sashafirsov commented on Oct 2, 2026

ruv commented on Oct 3, 2026

sashafirsov commented on Oct 3, 2026

ruv commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions