The tangled web of XSLT browser support

The Extensible Stylesheet Language Transformations (XSLT) language is used by web browsers to style XML content to make it easily readable; XSLT is part of the HTML living standard that is maintained by the Web Hypertext Application Technology Working Group (WHATWG). Only a small fraction of web sites serve content that requires web browsers to support XSLT, in part because major browser implementations have neglected the technology over the past 25 years. Now, it seems, they would like to rid themselves of it entirely. A plan to disable XSLT in Blink (Chrome's rendering engine) and a pull request by a Google Chrome developer to remove mentions of the specification from the HTML standard have been met with opposition, but arguments in favor of XSLT have proven ineffective.

What is XSLT?

While XML documents are suitable for consumption by computers, they are verbose and not particularly readable by humans. XSLT was developed as a language for transforming XML documents into other formats such as HTML, plain text, or other XML formats. When an XML document is served to a web browser with an XSL stylesheet, the browser can render the document into something more suitable for the user to read. For example, the US Congress web site serves legislation as XML with an XSL stylesheet, such as this bill from 2021.

All of the major web browsers (Chrome, Firefox, Safari, etc.) support client-side XSLT rendering, but they only support the 1.0 version that was finalized in November 1999. XSLT development has continued; the current 3.0 version of the standard was finalized in 2017, but the major browser vendors have shown little interest in keeping up with XSLT developments in this century.

Chrome and Safari use libxslt, while Firefox uses the TransforMiiX XSLT processor. LWN covered some of the history of libxslt in June; that implementation has suffered from a lack of resources for quite some time, and the longtime maintainer, Nick Wellnhofer, announced he was stepping down in June. Iván Chavero has offered to take over the project, and was vouched for by Federico Mena Quintero. He will, however, need to get up to speed with XSLT and the code base for the project.

It is worth noting that client-side rendering is not the only option for using XSLT to render XML as HTML for viewing in a web browser. There are a number of open-source projects, such as Apache Xalan and Saxon, that offer server-side processing for XSLT.

Google has sought to drop support for XSLT a few times. In 2013, Adam Barth notified the Blink development list of an intent to deprecate and remove XSLT from the browser engine. Barth argued that the inclusion of XSLT added "more than its share of complexity, which leads to security vulnerabilities", and that dropping XSLT support would help to remove Blink's dependency on libxml. Ultimately, the proposal was put on hold.

Dominic Cooney tried to deprecate and remove XSLT from Chrome in 2015. After much discussion, Rick Byers replied that Chrome's API owners had met and agreed that they would like to eliminate XSLT from Blink eventually. However, prior experience had taught the team that it was important to do so carefully and with a plan to "minimize the user and developer pain". Byers provided a list of components that such a plan would need to have, including real-world case studies for replacements and a deprecation timeline of up to two years. It is unclear if Cooney submitted such a plan, but a decade later Chrome still ships with libxslt and supports XSLT 1.0.

Call for removal

Removing XSLT from the HTML specification was on the agenda for WHATWG's meeting in March. During the discussion Stephen Chenney expressed concern that usage of XSLT was higher than the use counters indicated, and Dan Clark said "even if the data were accurate, not enough zeroes for the usage to be low enough" for removal (minutes here). Freed suggested during the meeting that "we could just mark it deprecated in the spec, to make the statement that we're not actively working on it". Brian Kardell said that it would be possible to remove XSLT from the MDN web documentation as well. "This would be the first time we have something baseline widely available that we've marked as removed", he noted.

After a few more comments proposing alternatives for developers, it was decided to punt the topic to the next meeting, which was then canceled. The topic was not on the WHATWG meeting agenda again until August, after Mason Freed posted an issue to discuss removing XSLT. Freed said that browser implementations of XSLT were frozen in time with the 1.0 standard, and that the underlying libraries for XSLT, such as libxslt, are aging code bases that are "notoriously susceptible to memory safety vulnerabilities".

He also claimed that there had been a significant decline in client-side usage over the years; he later followed up with a calculation that only one out of 7,891 page loads involves client-side XSLT. The topic of dropping XSLT was skipped during the meeting on August 8, because Freed was absent. Despite that, Freed opened the pull request on August 14 to remove XSLT from the HTML specification.

Anne van Kesteren said that Apple's WebKit team "is cautiously supportive" of removing XSLT, but would likely wait for one implementation to fully remove support. Olli Pettay indicated that Mozilla was also supportive, but cautioned that browsers should add console warnings about the deprecation sooner rather than later. Freed posted links to a WebAssembly (Wasm) polyfill that would process XSLT in the browser without relying on native browser features, to demonstrate that it was possible to move the functionality out of the browser while retaining support.

Discussion

While browser makers were supportive of Freed's push to get rid of XSLT, many others from outside the browser-making group weighed in with questions and objections. For example, Alberto Betella agreed that the security concerns were real, but argued that there is a "real-world and modern use case from the podcasting industry" to use XSLT to beautify raw podcast feeds:

RSS feeds remain one of the last open and decentralized distribution mechanisms on the modern web. Platforms like Spotify and YouTube are increasingly moving toward exclusivity and closed podcasting ecosystems. Supporting browser-side XSLT helps keep RSS accessible and human-friendly, especially for independent creators. This ties in directly with the ethos of openness that underpins the web itself, and also the work of groups like WHATWG.

Freed replied that there was no attempt to change RSS or XML, just the XSLT that is used to make the RSS feeds readable if users click on a link that loads an XML file. He wondered if there might be a way to add a processing instruction to the XML to redirect to an HTML page when the client is a browser.

Some favored the proposal to remove XSLT; Tab Atkins Jr. thought it was fine to remove XSLT from browsers, and said it should be "relatively trivial" to generate HTML from XML on the server:

I don't think there's a strong "Open Web" argument to be made here. XML data files being able to be reformatted into HTML is somewhat of an accident of history; we don't have similar functionality for any other data type, despite, for example, JSON files being vastly more common on the web than XML.

But Timo Tijhof replied that early web browsers had built-in feed browsers and native previews of when users would navigate to RSS feeds, "akin to PDF, JSON, and video viewers in browsers today". Now, there is a missing link in the path between clicking an RSS feed link and opening it in a feed reader. There is a reasonable argument to be made that XSLT is not good enough, he said, "and that we need something even easier to adopt".

Aram Zucker-Scharff, said that getting rid of the capability to visually render RSS feeds would mean "signing a death warrant for RSS feeds as an open technology". He warned that site owners would have to alter pages to link to specific platforms "that enclose and intermediate and disappear the open RSS feed", and echoed Betella's concerns that large companies had already pushed to "enclose" RSS within specialized readers, especially for podcasts.

He said that the "exodus from Twitter" had caused renewed experimentation with RSS, XML, and XSLT. Any solution that does away with native rendering of XML in the browser "is inevitably bad for the web platform's health".

The XSLT implementations are "riddled with CVEs" only because of neglect, Dorian Taylor said. Browser vendors have kept XSLT 1.0 parsers around, but have put as little effort into maintaining them as possible. He proposed that XSLT should be rehabilitated rather than scrapped and asked, "is there truly no appetite for a standard language for transforming markup, a thing we all have to do, on every project, all the time?"

Many other people weighed in to voice support for XSLT in the browser. Freed replied that it was clear that talk of removing XSLT struck a nerve, but he reiterated that the implementations shipped today were old, not well maintained, not widely used, and "a serious risk to all users, not just those who actively use XSLT".

He also acknowledged posts asking for improvement and renewal rather than removal, but argued XSLT was simply a technology that "didn't stand the test of time for client side usage in web browsers". (Emphasis in the original.) The Chrome team was "strongly convinced that this would not be the right way to spend our limited resources".

Shutdown

Taylor pointed out that Google is "literally a 2.5-trillion-dollar company" and that it was the browser vendors that chose not to keep up with XSLT. That comment was later hidden by moderators as off-topic, though it can still be viewed if a user is logged in to GitHub. A number of other comments were hidden as off-topic, and the thread was eventually locked to outside comments.

Freed left a final comment on August 19, in which he said that he cares about the health of the overall web:

I want to minimize the pain folks are feeling about this discussion of XSLT removal. But it's important to remember that ordinary users that fall victim to security vulnerabilities also feel pain, and I'm trying to minimize that too. I proposed some solutions to the concrete use cases I heard in this issue. If there are still gaps, I'd like to work on closing them. It's too bad we can't have that discussion here - I'm guessing we can't re-open this issue for outside comments, due to the overall tone of past comments. Either way, from now on, I'll only be responding to technical conversations, and ignoring the rest, for my own sanity.

The pull request thread was also locked to WHATWG collaborators as "too heated". Shortly after that Domenic Denicola, another member of the Chrome team, commented to remind Freed to update the XSLT section of the DOM living standard as well.

Stage one

The WHATWG has a series of stages for a proposal to be merged into the HTML standard. Currently, Freed's proposal is at stage one, the "incubation" stage, and looks to be headed to the second stage, "iteration". According to WHATWG's documentation, that would signify an expectation that a proposal will be eventually merged into the standard. Usually stage two is accompanied by "a prototype in at least one browser engine".

Barring a sudden reversal, the Chrome team looks poised to ship that prototype before too long. The Chrome Platform Status page for the "feature" to deprecate XSLT lists 2026 as the estimated shipping year, though many of the details for the deprecation plan are still left blank. The page does note, in something of an understatement, that "existing users of XSLT are understandably negative on this removal".

After a number of attempts to dump XSLT, it appears that the Chrome team is finally on its way to making that a reality. Whether the effects of that are as dramatic as the XSLT proponents have suggested remains to be seen; it does, however, seem like a loss for the open web overall.