The tangled web of XSLT browser support [LWN.net]

By Joe Brockmeier
August 27, 2025

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.

to post comments

RSS

Posted Aug 27, 2025 18:41 UTC (Wed) by josh (subscriber, #17465) [Link] (10 responses)

> 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"".

That makes no sense. The point of RSS is to read it in a feed reader, not a browser. If someone is looking directly at an RSS feed, it's probably not intentionally because they want to read the content. For most people I'd expect it to be a net improvement to render a direct RSS link as "This is an RSS feed, the title is XYZ, here's a set of feed readers you could read it in". *That* would bolster RSS adoption.

RSS

Posted Aug 27, 2025 19:22 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

I don't understand either

I do not understand the overall issue, to be honest

If someone wants to format xml in all kinds of way and cannot/will not do that server side, plugins are a thing; Some exist to modify json and xml in prettier format, so this seems like a sane way to resolve the situation

RSS

Posted Aug 27, 2025 20:05 UTC (Wed) by josh (subscriber, #17465) [Link]

I can understand the overall concern: this has been supported by web browsers for a very long time, and it breaks backward compatibility to take it away. That doesn't mean that it can't be, but it is important to replace the use cases (in a fashion that works for the current users, not just what people might hope the current users will switch to).

So, for instance, rendering helpful text for RSS feeds rather than raw XML, without requiring sites to do something different like server-side rendering, when they might not have any ability to run server-side anything.

RSS

Posted Aug 27, 2025 19:41 UTC (Wed) by jzb (editor, #7867) [Link] (5 responses)

If someone is looking directly at an RSS feed, it's probably not intentionally because they want to read the content.

Right, that's kind of his point. Web browsers don't natively handle RSS feeds anymore, so if a site includes a button for their regular RSS feed (rather than a link to Spotify or Apple Podcasts, or Feedly for regular RSS) and the user clicks it they just get the raw XML. Or, currently in Firefox, raw XML with the "This XML file does not appear to have any style information associated with it. The document tree is shown below." message which is not particularly friendly for most users.

With XSLT a site can provide something like this for an RSS feed: https://www.bennadel.com/rss, or this, which helpfully includes a little box at the top that explains what an RSS feed is and a link on how to use them. That's basically what you're describing to provide a "here's a set of feed readers" etc.

I may be wrong, but I don't think it will easily be possible for people who run WordPress or other blogging software on shared hosting to do server-side XSLT processing. That's a lot of feeds that won't be shown correctly if client-side XSLT processing goes away. (As an aside, that's a lot of feeds that aren't even discoverable if the site owner doesn't provide an RSS link, and/or the user doesn't have an extension that discovers RSS feeds for their browser... I use the Want My RSS extension to discover feeds in Firefox...)

RSS

Posted Aug 27, 2025 20:03 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

That's exactly what I'm suggesting that modern browsers should build in: recognize the RSS format and print a helpful message at the top, rather than just rendering it raw.

RSS

Posted Aug 27, 2025 20:18 UTC (Wed) by jzb (editor, #7867) [Link] (1 responses)

That would be great - but they've all explicitly moved away from supporting RSS, so I'm not holding my breath that they'd re-implement any RSS support to phase out XSLT. Perhaps I'm being too pessimistic, though... It's never happened before, but maybe this time...

RSS

Posted Aug 28, 2025 15:44 UTC (Thu) by iabervon (subscriber, #722) [Link]

I'd be happier if they moved to not trying to render RSS content either specially or as arbitrary XML, and defaulted to something that states that it's RSS and gives the URL in a way that's easy to copy into a program that does handle RSS. I always found it annoying that some sites had a link to a page that had the URL for the feed in it that I could look at and copy, and some had a link to the feed, and if I clicked on the link to the feed, the browser would act as a poor RSS reader that doesn't have my history and isn't integrated with my other feeds and also doesn't make the URL to copy easy to get.

RSS

Posted Aug 27, 2025 20:47 UTC (Wed) by archaic (subscriber, #111970) [Link]

I'm not convinced it was ever a good idea for web browsers to handle _any_ content that came over their sockets in a pretty human-readable away. I support the removal of xslt and even rss processing in a browser, but not the removal of xslt as a stylesheet format. If we were talking about a purely API-based middleware between a browser and a "unified" backend (possibly like libxslt) then technically it is no longer the browser doing any heavy lifting, is it? But then, I also don't want a browser to be opening any executable that might hand arbitrary data to arbitrary backends, either. Perhaps, as the protocol name expressly states, only HTTP data should be supported by a browser? ¯\_(ツ)_/¯

> https://www.bennadel.com/rss

Looks perfectly readable in raw curl output. Should curl make it prettier? I do not think so. The right app for the job. Browsers are not the right app for most jobs, though you wouldn't know that looking at all the jobs put on them.

RSS

Posted Aug 27, 2025 23:42 UTC (Wed) by jkingweb (subscriber, #113039) [Link]

> Web browsers don't natively handle RSS feeds anymore, so if a site includes a button for their regular RSS feed (rather than a link to Spotify or Apple Podcasts, or Feedly for regular RSS) and the user clicks it they just get the raw XML.

Not that you aren't correct in general, but Vivaldi does have an integrated feed reader, and you can subscribe to a feed using a button on the feed's readable representation (I assume this is achieved with XSLT, but I haven't checked).

RSS, or in eneral: raw data

Posted Apr 30, 2026 15:22 UTC (Thu) by mro1 (guest, #183531) [Link] (1 responses)

> That makes no sense.

it does, however I wouldn't be as dramatic, hear me out.

Xslt is a unique way to add visual to raw data. The often referred to 'separation of content and style'. CSS adds visual to html. Xslt can add markup to xml. In the browser. On the fly. The server just has to serve static assets. Rendered by the client. Without javascript or alike.

That way one can publish immutable raw data and still provide crisp, vivid visuals and still have a single, immutable source of truth. Publicly available. With very low technical requirements - a webserver serving static assets is enough.

There's no other way to achieve such a thing AFAIK.

RSS, or in eneral: raw data

Posted Apr 30, 2026 16:35 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

You can statically render the data on the webserver. And server static resulting files. Without depending on client functionality.

Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 27, 2025 19:39 UTC (Wed) by farnz (subscriber, #17727) [Link] (9 responses)

It looks to me like the direction of travel is JavaScript for all conversions of input data to renderable HTML; there appear to be pure JavaScript XSLT implementations, and thus this ends up being like PDF.js, just another way to convert from a non-HTML source to something the browser can render, using JavaScript to do all the hard work.

You end up with a "web platform" that's HTML5 + CSS + JavaScript, where the JavaScript does the heavy lifting client side to take interesting inputs (as XML, JSON, or something else) and provide something the web platform can render.

Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 27, 2025 20:45 UTC (Wed) by iq-0 (subscriber, #36655) [Link] (6 responses)

Eventhough I despise "code as an alternative to mark-up" in general. I think this is a good use case for these kinds of semi-legacy formats. The in-browser implementation suck and are not consistent across vendors. The javascript (which is generic enough to execute properly on all browsers) brings us to a level playing field, thus creating an evironment for generally available incremental improvement.

If XSLT (especially newer versions) turn out to be popular it will start benefiting from optimized browser support. Should it turn out to be a dud then at least all browsers are able to represent all the documents and format that assumed it would be a success, keeping the open web access alive.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 8:43 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

I, in general, don't really care how you convert the raw data to something pretty for the user to view. JavaScript and XSLT both work for me here, with JavaScript having more flexibility.

The thing that I do want to see more of, and that XSLT was supposed to usher in (but didn't, for a variety of reasons) is a world where the data is separate to presentation. If that's data supplied as XML and transformed into a presentation form by XSLT, great. If it's supplied as JSON, or XML, or CBOR, and transformed into a presentation form by JavaScript code, that's also great.

Key for me, though, is that the data is supplied separately, and that I can, as a hacker type, use the presentation renderer to reverse-engineer the data format and reuse the data in ways the originator did not think of. It's also a nice side-benefit if the presentation layer (whether XSLT, or JavaScript) is highly cacheable, so that the data is small; I'd prefer to get the data in a single TCP packet each time it updates, rather than downloading 200 KiB of "echo" formatted HTML (or 200 KiB of XML for 100 bytes of new data, for that matter).

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 16:25 UTC (Thu) by wahern (subscriber, #37304) [Link] (4 responses)

Compare the podcast ecosystem to the YouTube and Instagram ecosystem. In which ecosystem is the presentation layer tightly integrated with the media data delivery layer? Which ecosystem has standardized and *reliable* metadata and data formats? Which ecosystem has a plethora of both web and native apps that can access content across multiple (or even indefinite) number of media hosts? Which ecosystem are you more likely to even be able to access the raw media without the presentation layer acting as a kind of DRM? Which ecosystem has become more monopolized and centralized by big players?

Now ask yourself, why is that? What's better technologically for a single outlet is not necessarily better for the health of the broader ecosystem. Technology shapes and channels how players interact. Once upon a time the FOSS world, or at least part of it, understood that. But we've all become utterly inured to centralization and walled gardens that few can even remember the previous era, of which RSS is a vestige. There's an alternative universe where Spotify is the singularly dominate player in podcasting, similar to YouTube and Instagram for video. Would that be a better universe?

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 16:50 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

I don't think any of that is particularly related to XSLT, however. One of the reasons XSLT is so lightly used is that nobody bothered with it back in the day; even now, it's common for RSS feeds to not also have an associated XSLT transform to give you a nice web page if you open the RSS feed directly.

Rather, it's about money. Video and photo sharing centralised because, at the time, bandwidth prices were high compared to the sizes of files; the YouTube and Instagram gambles, (which paid off) were that if you could grow fast enough, you could get enough investment to allow you to stay ahead of the cost curve, up until bandwidth became cheap enough that they could cover their costs from their income.

Had the typical home user had an unlimited usage 100M symmetric connection back in 2004, with 10G being cheap in datacentres, we might well not have seen the centralisation we say, because it would have been cheap to host your video yourself, and therefore extending the podcast ecosystem to a videocast ecosystem would have been something people did.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 18:22 UTC (Thu) by wahern (subscriber, #37304) [Link] (2 responses)

I don't think XSLT is the reason the podcast ecosystem was successful. There were and are alot of dynamics at play. But I appreciate the argument that XSLT has helped it survive in the face of all the pressures it now faces, particularly from commercialization; i.e. that it helps to (indirectly) preserve sufficient diversity to stave off catastrophic centralization. I doubt XSLT is even the most important factor today, but perhaps it's important enough that in its absence the ecosystem will collapse, it's loss being the veritable straw breaking the camel's back. Dropping XSLT could introduce just enough friction among users that usage patterns and expectations (of listeners, producers, hosters, aggregators, etc) shift in a way that allows the market to be terminally captured.

Also, I'm admittedly biased because I really do like XSLT. I dislike XML, and dislike XSLT's XML syntax, but in terms of functionality and longevity, even prospectively (alternatives aplenty, but always ephemeral), there's nothing else like it. Saying that browsers don't need XSLT because we have JavaScript is like saying browsers don't need WebRTC or PushAPI because we have JavaScript, WASM, and HTTP 1.1. Sure, but that's beside the point. Even though XML is seemingly in its golden years, I wouldn't be surprised if it's still more ubiquitous in terms of breadth and depth of software support and data encapsulated than JSON. All the world isn't a Rest API. And manipulating XML is much nicer using XSLT & friends (XPath, XQuery, etc). And despite the WHATWG's best efforts, XML and HTML remain sufficiently alike that it strains credulity to suggest XSLT couldn't or shouldn't be a contender for HTML templating.

The most convincing argument against XSLT for me is the lack of well maintained libraries. So what's clearly necessary, if not sufficient, for XSLT to survive is the FOSS community stepping up to fill the vacuum--libxslt successfully revived (thankfully some people are already taking a stab at that), Saxon opening up more and seeing greater adoption, or some newcomer library/ies. Preferably all of the above.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 18:33 UTC (Thu) by wahern (subscriber, #37304) [Link]

To be clear, by "Dropping XSLT" I meant "Dropping browser-native XSLT and therefore losing the single URL model of podcast sharing and integration". Because it's not XSLT, per se, that is argued to undergird the ecosystem, but the single URL model. It's like flipping the YouTube model on its head, where a YouTube link functions as both a link to the raw video that can be followed by any HTTP-aware software, but also happens to magically render a convenient (yet host-controllable) UX when opened by a web browser. It's an artifact of the way the latter aspect works that helps to protect the viability and persistence of the former--open-access to the raw media.

Separating data and mark-up - JavaScript versus XSLT

Posted Aug 28, 2025 19:35 UTC (Thu) by excors (subscriber, #95769) [Link]

I suspect the main reason podcasts have avoided centralisation is that listeners are generally split between Spotify, Apple Podcasts, and increasingly nowadays YouTube, with a pretty small fraction from all the other platforms combined. In particular Apple Podcasts could never have become a monopoly, because not everyone has an Apple device, but podcast creators have to support it because a lot of people do have an Apple device.

Following the zero-one-infinity rule, since podcasters have to support more than one platform they'll use a third-party hosting service who know how to publish to all the platforms at once (and how to handle listener stats for all those platforms to attract advertisers, etc), so the minor platforms can still hang on. But I think it's the duopoly of commercial platforms who have allowed the industry to take that shape.

Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 27, 2025 22:42 UTC (Wed) by wahern (subscriber, #37304) [Link] (1 responses)

I suspect most people would be happy with a PDF.js-like solution.[1] The point of contention is whether it would be integrated into the browser, like PDF.js is with Mozilla, or whether you have to explicitly bootstrap it by emitting a snippet of HTML and JS to get the ball rolling. The whole debate regarding RSS is about the importance to the open ecosystem of being able to share a single URL, and to do so without requiring any specialized server-side application logic and client detection.

Imagine if browsers couldn't display PDFs, either natively or by reliably being able to pass it off to a local viewer. PDF as a open document format would lose much of its value, and walled gardens would flourish even more. This dynamic is precisely why YouTube makes it extremely difficult, if not impossible, to directly pull a video. Making the content tightly bound to their viewing platform is integral to how they achieved and maintain their dominance. It would appear (at least based on the claims) that RSS, like SMTP, achieved escape velocity before the dominance of walled garden platforms squashed the ecosystem, but that dynamic largely rests on built-in XSLT support.

Direction of travel seems to be JavaScript for all of this sort of thing

Posted Aug 28, 2025 8:32 UTC (Thu) by farnz (subscriber, #17727) [Link]

PDF.js was prototyped outside the browser, and integrated when it was clear that it was useful (to replace PDF plugins, admittedly).

I don't see any strong reason why the same couldn't happen with XSLT; people show cool tech demos outside the browser, using a JavaScript based viewer for their XML format (which is something that most of the usage of XSLT I've seen, bar the trick of making an RSS feed pretty, could do easily - they're currently serving an XML data file and XSLT file to generate a web page, they could serve a HTML5+JavaScript+CSS fileset and an XML data file).

The RSS use would need a bit more server-side assistance to serve the web page to browsers, and the RSS feed to RSS readers, but would at least be something you could prove works well, before asking browsers to integrate xslt.js.

XSLT is kinda of horrible

Posted Aug 27, 2025 23:12 UTC (Wed) by roc (subscriber, #30627) [Link] (3 responses)

XSLT is awful to use. Using XML as a syntax for stylesheets and code is nasty. Also, ultimately you want to write transforms in a real programming language, and extending XSLT into more of a real programming language sounds horrendous.

Of course, being technically horrible isn't the only thing that matters, but it partly explains why XSLT isn't much used and why browser vendors aren't more enthusiastic.

XSLT is kinda of horrible

Posted Aug 27, 2025 23:46 UTC (Wed) by basscomm (guest, #125799) [Link]

I see this sentiment a lot and I have to admit that I don't understand it all. I admit that I'm some kind of outlier here, but I've been been refreshing my XSLT over the past few years to convert some XML to HTML on a hobby site, and I don't find it particularly hard to understand or use. Sure, that opinion might change if I ended up doing anything more complex, but for basic stuff, it's really not that bad.

XSLT is kinda of horrible

Posted Aug 28, 2025 1:22 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

The aesthetics aren't really part of the argument, XSLT is an open standard with multiple implementations which exists, and is built for a different vision of the web built out of information sharing than the dominant advertising and surveillance supported one built by big tech companies. Using XSLT to build a web view client-side means that the client has access to the rich XML data too, with the great example of RSS, which is not tied to any particular vendors software stack (get your podcasts *wherever* you get them), which is a very radical feature given how much of the modern web is driven by FAANG, which uses web technologies, like JSON and JavaScript, but tends to be locked in bespoke APIs and difficult to maintain frameworks which limit integration to large companies which can afford it. This isn't a technical argument about the merits of XSLT, it's mourning of a way of being. RETVRN ;-) There is some technical meat though, if the XSLT engine had been maintained, if Apple and Google or MS had thrown a few FTE to the project then maybe it could have been updated to XSLT v2 and v3 which supports templating JSON data as well, and that have might lead to a very different kind of design for PWA and SPA than what React (Facebook) and Angular (Google) evangelized, none of which works toward the strengths of the browser engine or the web as an information-sharing platform, SPAs tend to obfuscate the underlying information and do not lend themselves to custom user-agent behavior in the way RSS does.

This whole argument is difficult to articulate because it's an emotional, vision and alignment discussion and not primarily a technical one

No REST for the wicked

Posted Aug 28, 2025 7:19 UTC (Thu) by tux3 (subscriber, #101245) [Link]

There isn't exactly a bijection between XML and JSON, but I don't find that the way it's rendered makes that much of a difference on access to the raw data

I usually have little trouble getting raw data in the modern JSON/Javascript Zeitgeist. And it'd be writing very similar Python scrapping snippets in an XML/Javascript or XML/XSLT world

Either way if I'm going to be doing anything interesting with the data, it won't be by manually copying bits of data from my browser's debug view, I'll be calling some bespoke API. If anything, the olden XML APIs I'm forced to use sometimes have this distinctive flavor of over abstraction and unnecessary complexity.

Data's data. The presentation layer doesn't really change access, in my experience

Sad if it happens

Posted Aug 27, 2025 23:55 UTC (Wed) by ErikF (subscriber, #118131) [Link]

I remember using XSLT as the server-side formatter for the Web site where I worked at in the late 1990s. It worked really well, but support for XSLT itself on the browser side was sketchy so we decided to not bother trying to make it a client-side thing when HTML was already a dog's breakfast. Now it looks like XSLT is going away. I guess that I understand: it never really was a popular client-facing technology, but I bet that on the server end you'll see it for a long time yet.

Allow me to pay my respects for XSLT's ignored cousin, XSLT-FO. You never really were given a chance to shine: I tried using you to be able to make both Web pages, e-mails and documents. You gave it a valiant effort but it didn't ever seem to work properly.

Its time is gone

Posted Aug 28, 2025 9:17 UTC (Thu) by dottedmag (subscriber, #18590) [Link]

Lots of wild Web-adjacent technologies were bubbling in the minds back then. Some of them somehow got accreted to the browsers and ossified, some of them stayed outside and withered.

With 25 years of hindsight, it's obvious that XSLT is not a smashing success. A technology like that would not pass the bar for being added to browsers today. Good riddance!

Adopt XSLT 3.0

Posted Aug 28, 2025 11:48 UTC (Thu) by pabs (subscriber, #43278) [Link]

There is also a proposal for browsers to adopt XSLT 3.0:

https://github.com/whatwg/html/issues/11578