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.

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:

1. 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.
2. 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.
3. 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 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!):

1. 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.
2. The external library needs to implement enough XSLT 1.0 and EXSLT compatibility that existing Web content written for libxslt and Tranformiix keeps working.
3. 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.

I've tagged this as addition/proposal New features or enhancements because this is a request to adopt XSTL 3.0, but also I've tagged it needs implementer interest Moving the issue forward requires implementers to express interest to clarify the fact that right no there are no browser implementers who have agreed to take a supportive position of implementing XSTL 3.0. This is a procedural matter, for the purposes of issue triage in the WHATWG HTML issue tracker.

Usually for feature requests we'd ask that you follow the template provided, and as a policy matter tend to close issues out, asking them to be re-opened with the template, but I am conscious that might be seen as me attempting to silence discourse, so I'm going to avoid doing so in this instance. However, to anyone reading this, if you're interested in raising new feature requests for the standard please use the new feature issue template.

I strongly support the proposal.

The community using XSLT is vibrant and growing. The difference between version 2.0 and 1.0 is night and day. Version 3.0, with first class support for arrays and maps, provides highly performative transformations in a declarative mode. Version 4.0 is under development right now: https://qt4cg.org/

XSLT 1.0 is extremely limited, and difficult to work with. More recent versions are delightfully expressive and powerful, and open up to ordinary people the ability to do highly complex styling and transformation. With XSLT 3.0 it is possible to do things that are very, very challenging to do in Javascript and other browser-supported technologies.

I appreciated learning about the security flaws pointed out by Frantric in his talk, but I disagree on the diagnosis. In my opinion, the problem is not with XSLT, but with old technology, and the underlying rules that dictate how XSLT and Javascript are allowed to interact.

I also strongly support the idea of creating a new implementation of XSLT 3.0 in a memory-safe language and integrating it into browsers as part of the standard. I don't see how security is more of an issue with XSLT than it would be with JS, which can similarly rewrite the entire DOM of a web page and introduce any content it likes. In addition to the RSS-feed community, there are text-encoders, document curators, and digital edition specialists all over the world generating large quantities of HTML content statically offline using e.g. the Saxon XSLT processor, then pushing it to web servers; the benefits of being able to do this work in the client browser would be huge. The ability to offer different versions or configurations of entire sites based on user needs and preferences, but based on a single XML source, would be very powerful.

There are several additional points.

1. Lack of implementer interest is sad, but it's nothing that cannot be fixed. SVG was in limbo for a long time (IIRC there was talk of removing it from the spec, too), but then interest picked up, and now SVGs are an indispensable part of the web
2. There's currently literally a discussion on implementing a new templating system for the web. See https://justinfagnani.com/2025/06/30/what-should-a-dom-templating-api-look-like/ and [templates] A declarative JavaScript templating API WICG/webcomponents#1069 when we already have a powerful templating system that can be native to the browser and even work without JS if needed.

2. There's currently literally a discussion on implementing a new templating system for the web

@dmitriid Oh, that's not good. While XSLT can be supported outside browsers, that templating API will again just make it harder to implement truly independent web browsers by bloating the web standard, making everything depend on Chromium in practice, because other vendors won't be able to keep up.

With XSLT, we can avoid that because it's easier to implement and not tied to the web ecosystem that much...

I'm someone who regularly teaches XPath and XSLT 3.0 (and looking ahead to 4.0) in the context of a Digital Media program that combines Digital Arts and Digital Humanities. In my world, the teaching of XSLT is part of Digital Humanities coursework and associated with document data modeling, digital publishing, and media transformations. It looks like this is where you're observing the most evidence of the ongoing relevance of client XSLT in the browser, with RSS feeds and podcasts, but as @martindholmes mentions, there are other uses in developing static websites and also in document data modeling and transformations to scalable vector graphics (SVG). In my university program, XSLT is very much about style and design templating, a language that our students learn to design with as a creative medium alongside CSS.

We haven't been trying the old XSLT 1.0 browser clients, but that's because they're outdated. Instead we tend to run XSLT transformations before publishing to the web. If we had a viable 3.0 client that would be amazing. As @Arithmeticus observes, XSLT 3.0 is especially powerful for outputting maps and arrays (and 4.0 will be even more convenient): It's efficient and practical for those who need intricate JSON structures, for designing JavaScript-based web interfaces as well as in making knowledge graphs and feeding "ground truth" data to LLMs.

So in my program I'm finding XSLT increasingly important to teach for that reason: Stylesheet templating in XSLT 3.0 is a powerful way to learn how to express a JSON map structure working with markup source data. This fall, we'll be teaching XSLT 3.0 right alongside Node JS applications, and these are both complementary power-tools for our students. The latest XSLT is also taught at XML Summer School and other venues attracting Digital Humanities people like me. The current XSLT is a highly preferred and accessible programming idiom for those "in the know" about it.