{"id":49004,"date":"2025-08-21T14:30:03","date_gmt":"2025-08-21T18:30:03","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49004"},"modified":"2025-11-18T11:10:00","modified_gmt":"2025-11-18T16:10:00","slug":"removing-xslt-from-the-web-platform","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/08\/21\/removing-xslt-from-the-web-platform\/","title":{"rendered":"Removing XSLT From the Web Platform"},"content":{"rendered":"

Mason Freed<\/a> (Hacker News<\/a>):<\/p>\n

XSLT v1.0, which all browsers adhere to, was standardized in 1999<\/a>. 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<\/a> 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. The underlying libraries that browsers use to process these transformations (e.g. libxslt<\/a> in Chromium) are complex, aging C\/C++ codebases. This type of code is 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<\/a> that continue to put browser users at risk.<\/p>

For these reasons, I’d like to raise the question of whether we should deprecate and remove XSLT from the web standard.<\/p><\/blockquote>\n\n

Terence Eden<\/a>:<\/p>\n

August 1st<\/a> - Googler asks the community if XSLT should be removed from the HTML living standard.<\/p>

Respondents overwhelmingly reject the suggestion.<\/p>

August 6th<\/a> - Google starts work on removing XSLT from Chrome.<\/p>

August 14th<\/a> - Googler sends PR to remove XSLT from the standard.<\/p>

Like, I don’t have a particular view of whether this is a good idea or not. But these sham community engagement exercises piss me off.<\/p><\/blockquote>\n\n

Most of the critical comments got marked as off-topic or duplicates, and then the bug was locked.<\/p>\n\n

spankalee<\/a>:<\/p>\n

This isn’t Chrome doing this unilaterally. […] representatives from every browser are supportive and there have been discussions about this in standards meetings […] You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time.<\/p><\/blockquote>\n\n

Oblomov<\/a> (via Hacker News<\/a>):<\/p>\n

What I want to talk about in this article is the war Google has been waging on XML<\/a> for over a decade,\nwhy it matters that they’ve finally encroached themselves enough to get what they want,\nand what we can do to fight this.<\/p>

[…]<\/p>

Just as RSS feeds are making a comeback<\/a>\nand users are starting to grow skeptic of the corporate silos,\nGoogle makes another run to kill XSLT<\/a>,\nthis time using the WHATWG as a sock puppet.\nParticularly of note, the corresponding Chromium issue<\/a>\nwas created before<\/em> the WHATWG Github issue.\nIt is thus to no one’s surprise that the overwhelmingly negative<\/em> reactions to the issue,\nthe detailed explanations about why XSLT is important,\nhow instead of removing it browsers should move to more recent versions of the standard,\nand even the indications of existing better and more secure libraries to base such new implementations on,\nevery<\/em> counterpoint to the removal\nhave gone completely<\/em> ignored.<\/p>\n

[…]<\/p>\n

For example, he omitted that two new major versions of XSLT have been released since\nthis technology was first implemented in the browsers: XSLT 2 in 2007, and XSLT 3 in 2017.\nThis means that when Google first proposed to kill XSLT<\/a>,\na newer, considerably more powerful version of the standard had been released for six years already.\nAnd already at the time people were pleading for browsers support to be upgraded to the new version.<\/p>\n\n

It is thus not by chance or by lack of resources that browsers are stuck with the 1999 XSLT 1:\nit has been an intentional choice against the users' will<\/em> since at least<\/em> 2013,\nthe year we already mentioned as the turning point for the centralization of the web.\nXSLT has been intentionally boycotted<\/em> by Google, Apple and Mozilla:\nusing the excuse that it is not widely used today, after decades of undercutting any efforts in adoption,\nrefusing to fix bugs or even to provide meaningful errors to assist in debugging related issues,\nis a complete mockery of the victims of these policy<\/em>.<\/p><\/blockquote>\n\n

Marco Arment<\/a>:<\/p>\n

Fun fact: David Karp saved the world from XSLT being Tumblr’s blog-theme language.<\/p><\/blockquote>\n\n

Previously:<\/p>\n