XSLT Debate Leads to Bigger Questions of Web Governance
XSLT (eXtensible Stylesheet Language Transformations) is a powerful tool with significant potential, but it’s currently poorly and sometimes insecurely implemented in web browsers — and (maybe because of that) not that widely used on websites. Is it better to remove it to improve security and free up browser makers’ budgets and resources for more popular features? That will mean webpages that rely on it will need to be redesigned and rebuilt to keep working. Or is it better to invest in bringing XSLT up-to-date, at the risk of making newer, more popular features a lower priority?
Browser makers like Google and Firefox asking this question have ended up in the middle of what quickly went from understandable expressions of frustration to an outspoken and sometimes acrimonious discussion, about not just browser development priorities and backwards compatibility, but about the intent and worldview behind those and the impact on the open web, rather than necessarily the value of the technology itself and how best to deliver it.
What Are All These Tags Doing?
Although XML’s focus on the structure of data was intended to make it readable for both humans and machines, it’s not really that readable for humans. XSLT lets you keep the separation between data and presentation, by putting your rules (using the XPath syntax for expressions) for how you want to transform the data in XML documents into a different order, a different layout, or even another format entirely — all in a stylesheet you can attach to your web page.
You can think of XSLT as a functional declarative language, but it’s for writing templates rather than algorithms.
In the early days of XML, being able to use XSLT stylesheets to dynamically transform content to the right format for the client – whether that was HTML with specific markup, a PDF document or just another XML document — right in the browser, without needing round-trips back to the server, was a useful tool for building web apps. A multipurpose XML file with styling applied via XSLT, which outputs exactly what’s needed in different situations, can be more efficient than publishing multiple HTML options or doing server-side processing.
Early e-commerce sites used it for turning XML product catalogs into websites. In fact, the reason Opera supported XSLT in the first place was that Google Maps itself depended on it, because it was serving XML and converting it to HTML for different browsers. Developers who want to overlay data on Google Maps or embed maps in their own pages also used XSLT. Now there are APIs for both; although pages using the XSLT approach may still be online and working.
XSLT continues to be widely used in digital publishing, especially for sophisticated output where you want to present complex documents using structured information in interactive ways — whether that’s fill-in-the-blanks templates for attorneys, historical records, manuscripts, multi-volume books or custom invoices generated on demand, all done inside the browser. XSLT can combine multiple sources and put them side-by-side on screen, like a document and its translation, plus comments and annotations.
But does that need to be done in the browser, especially when developers have the option of using JSON (which is arguably easier for humans to read), JavaScript, CSS and frontend frameworks like React, Angular or Vue? Especially when advanced users in publishing choose server-side options for XSLT that are far more powerful, up to date and easier to use than browser implementations still stuck on version one of a standard just about to reach v4, mostly relying on an open source library with a single maintainer that’s intermittently funded and hasn’t always enjoyed a good working relationship with those browser companies?
The proposal to deprecate client-side XSLT looks like an admission that browser makers failed to keep up with the standard and invest in a technology that should be more useful than it can be in its current state, which seems more of a liability. They argue that the usage of XSLT hasn’t justified more investment. But XSLT fans would call that a circular argument, because leaving the feature to stagnate made it hard for developers to adopt.
XSLT: How We Got Here
When XLST first emerged as a standard, Firefox and Microsoft wrote their own implementations. Internet Explorer 5.5 was the first browser to implement XSLT in 2001, which isn’t surprising as Jean Paoli, one of the editors of both the XML and XSLT specs, was working on InfoPath (an application for creating semi-structured documents) at the time.
IBM and Oracle also had XSLT implementations for their software platforms and once large vendors came out with those and the Apache Foundation created Xalan, there was little revenue to encourage smaller developers to do the same work.
The Qt fork of WebKit moved from its own implementation in 2011 to use the open source libxslt library — and the libxml2 library it depends on, described by the current maintainer as a hobby project; slightly ironically, that was because Qt hadn’t kept up with the standard and libxslt supported it better. Apple forked libxml2 and libxslt, both for WebKit and macOS (adopting existing Gnome components); something it often does to avoid accidentally disclosing future plans while only intermittently contributing changes back to upstream projects (it recently contributed security fixes for libxml2, though).
Chrome inherited libxslt and libxml2 when it forked Blink from WebKit – which means Microsoft now uses them in Edge (and the WebView2 wrapper for desktop web apps) – and has also contributed security patches and occasionally funded the maintainer with a grant. But while XSLT continued developing (version 3 of the standard came out in 2017, adding support for JSON and markdown as well as improved functions and variables plus maps, arrays and streaming support) and implementations outside of browsers like Saxon updated to support it, libxslt and browser implementations based on it didn’t. Despite occasional requests, Chrome not only didn’t update XSLT but marked it as obsolete in 2015.
In 2012, there was internal discussion about whether to remove XSLT support because usage didn’t justify allocating engineers to work on these bugs.
Similarly, the choices Firefox made about how to implement XSLT efficiently don’t support optional (but common in XSLT use) features for handling special characters. Web developers have been complaining about this for 24 years and counting; Mozilla’s response was that it would happily accept suitable code to add that feature, but it didn’t want to spend resources to work on something that would require major changes to how the XSLT engine interacts with the rest of Firefox.
In 2012, there was an internal discussion about whether to remove XSLT support because usage didn’t justify allocating engineers to work on these bugs; at the time, the decision was to keep what limited support Firefox already had.
In 2013, Google also suggested removing XSLT support from Blink because of low usage, because the way the libraries were integrated into Blink was complex enough to introduce extra security vulnerabilities and because removing libxml2 (required for libxslt) would allow the browser to change how it parses and presents XML. The suggestion wasn’t popular with web developers; comments in support of XSLT continued appearing for another five years. For one thing, even the best-known XSLT alternatives, like Saxon, don’t always beat the clunky old XSLT 1 implementation in browsers on performance.
But XSLT has already lost some functionality in browsers since then for security reasons. Older browsers used to let you open XML files on your computer with an XSL stylesheet; that’s now routinely blocked for security reasons, which doesn’t help new developers learn the language.
If you need to do that with local files where it’s not worth uploading them to a web server, there are a few options, including running a web server locally (the VSCode Live Server extension is a quick way of doing that). If you use Microsoft’s Edge browser, the Group Policy IntranetFileLinksEnabled in Edge 95+ lets you turn off the navigation blocking and have things work the way they did back in Internet Explorer, or you can launch Microsoft Edge or Chrome using a command-line argument that allows access. The mention of IE should clue you in to the fact that this is an old-school way of doing things with potential security issues.
Frustrations Boil Over
Security issues are part of why browser makers are talking again about removing XSLT support, although it’s not just about that. Security researchers at Project Zero and Positive Technologies reported some long-standing bugs in libxslt in May this year; although they were addressed, the libxml2 maintainer was frustrated with the lack of contributions from large downstream users like browsers, changed the project’s security policy in June to treat vulnerability disclosures like any other bug, and stepped down from libxslt. Handing the project over to a new maintainer, he described it as “the most thankless and frustrating job I ever did in my life”.
But even before that, Firefox had already raised the idea of trying again to remove XSLT from the browser in the March WHATWG meeting, because of apparently low usage — and the fact that the low usage means all browser makers allocate their resources elsewhere and can’t effectively address bugs reported in their XSLT implementations.
When the Chrome team created an issue on GitHub to discuss the idea of deprecating XSLT from the web platform and removing it from browsers as a “niche, rarely used feature” superseded by JavaScript and implemented by complex, aging codebases with little maintenance security scrutiny, replacing it with a polyfill (that sites would have to adopt) or browser extension users would have to install for sites where developers couldn’t switch to server-side XSLT, the intent was to continue the conversation Mozilla had started more publicly.
Chrome’s stated position is that improving XSLT in the browser rather than removing it isn’t currently “the right way to spend our limited resources.”
Unfortunately, the discussion quickly became so heated that multiple issues on the topic had to be locked, because along with the details of the different ways that developers rely on XSLT in the browser, it also became a proxy for debating the dominant position of Chrome in the browser market, the politics of where Google makes money and how to support open source, occasionally in very combative terms.
Although a more thoughtful technical discussion is continuing, Chrome’s stated position is that improving XSLT in the browser rather than removing it isn’t currently “the right way to spend our limited resources” and it’s focusing on finding alternatives to client-side XSLT.
So far that’s writing and promoting a polyfill for developers to add to their sites when they don’t want to run XSLT on their web server. Having XSLT in the browser has meant developers can use a cheaper server designed for static sites, but still serve dynamic pages or even use the browser as a build system, so these changes may make it more expensive and demanding to use XSLT. It only outputs HTML and also requires users to enable JavaScript in their browser (which is common but not universal). It’s also not clear what the impact on performance might be (the polyfill is in an early stage of development and not yet optimised).
Chrome will also wrap the polyfill as a browser extension for users: the current plan is to show a search of the Chrome extension store rather than pre-installing the extension, which means users will need to pick the correct extension rather than any malicious imitations that hackers try to add to the store.
Unused or Undetected
The tension between security and web compatibility is always a thorny issue. “The XSLT debate is really about two incompatible worldviews: browser vendors like Google who see a security burden with 0.02% usage [in 2013], and the enterprise developers who see irreplaceable infrastructure,” said Kate Holterhoff, senior analyst at RedMonk. “One side counts page views; the other counts patient records. They’re both right, and that’s the problem.”
Tracking usage of XSLT is complicated; browser statistics can show usage of both the XSLT processing instruction and the XSLTProcessor API in JavaScript, but only when telemetry is enabled. Many commercial organisations block that kind of telemetry, so the statistics are probably inaccurate for the enterprises that may be the heaviest users of XSLT. It’s been common for building intranets and older web apps relying on XSLT could be wrapped in Robotic Process Automation workflows or a source for agentic AI. Even Microsoft couldn’t tell us anything about enterprise usage of client-side XSLT.
“One side counts page views; the other counts patient records. They’re both right, and that’s the problem.”
– Kate Holterhoff, senior analyst at RedMonk
Equally hard to find statistics on are the embedded devices that rely on client-side XSLT in the browser for sending XML data (which can be much smaller than an HTTP payload) from an onboard web server to dashboards and control interfaces, where the XSLT can do anything from formatting date and time, or translating text for users in different locations, to transforming medical information into a friendly format for inclusion in hospital records.
The limited memory, storage and processing power available on microcontrollers will often mean the transformation can’t be done server-side, so dashboards and integrations would have to be reimplemented using JavaScript, with XML content that could be easily reused being delivered as HTML instead. Older embedded systems in networking, telecoms or medical informatics — where XSLT is widely used — are unlikely to get updated, so users would need to adopt browser extensions to continue using dashboards and configuration tools.
Counting desktop pages that trigger the XSLProcessingInstruction use counter in the HTTP Archive of the top sites on the web (taken from the Chrome User Experience Report) doesn’t necessarily give a representative figure for XSLT usage either, because the archive doesn’t crawl the whole site, just the initial URL.
The 0.001% of pages it finds with XSLT include sitemaps, RSS and Atom feeds, API endpoints, education portals (like archives and library sites), government information, sports results, webcam directories, and gateways for remote access enterprise apps. Chrome’s own statistics show an increasing number of forum sites using XSLT, although still a low absolute number.
The US Congress and other sites use client-side XSLT as one way to create pages for individual bills, the US National Weather Service and Canadian Forest Service weather station directory use it, the European Parliament uses it to show party political information, MySociety uses it to let millions of users build custom feeds for services like FixMyStreet, and the XMPP Standards Foundation uses it for documentation.
Large sites like these may already have alternatives and will certainly get updated if client-side XSLT goes away; that’s less likely for smaller sites. Older pages saved on the Internet Archive that rely on XSLT will just stop working.
There’s another popular use of XSLT in the browser: using it to turn RSS and sitemaps designed for RSS readers and search bots into nice-looking webpages that humans can read too (and reduce hosting and bandwidth costs by not needing twice as many pages).
The prospect of losing that option is behind a lot of the hostility to the idea of removing client-side XSLT. With the rise of newsletter platforms, nearly all of which offer RSS feeds (as do many fediverse services, while Bluesky has an RSS feed for every user), and the fact that podcasts are delivered as RSS feeds, removing a way to easily style RSS in the browser can feel like blocking an opportunity to foster the open web — just as open and decentralized systems are attempting to compete with walled gardens, content aggregators, and giant social media platforms.
That might align with Google’s interests, but it would be a decision taken at a much higher level than the browser engineers who are discussing this inside WHATWG.
Fast or Furious?
Removing features from the web platform is relatively rare and usually takes a long time — but it does happen. Removing (or changing) a browser feature might improve security, privacy or performance; and that gets weighed against the inconvenience that removal would cause to users and developers.
Some obsolete, deprecated features — like <font>, align= and <xmp> — are still broadly supported in browsers, for compatibility and because there’s no pressing reason to drop them. But of some 200 features that Chrome has considered removing or changing significantly (many of them experimental, but some that had shipped and been adopted), around 85% were approved for unshipping, based on the Blink principles of web compatibility.
“It’s a lengthy and involved process; once they went through that process, they decided there’s not enough out there to justify keeping this.”
– Eric Meyer, Igalia web standards advocate
That includes the removal of legacy JavaScript features like document.all.tags, which Igalia web standards advocate Eric Meyer suggested almost certainly broke some sites at the time, after weighing up the situation carefully. “It’s a lengthy and involved process; once they went through that process, they decided there’s not enough out there to justify keeping this,” he said.
Taking features out of all browsers can take a very long time. Mutation events (for tracking changes to the DOM tree) were deprecated from the W3C spec in 2011 because they could crash browsers or cause performance and security issues. Mutation Observers were introduced as a replacement in 2012, but the old APIs were still widely used in 2023 (including by Gmail and Google Docs) when the Chrome team started pushing to remove them. Even with enthusiastic agreement from Firefox and more muted support from WebKit, it took over a year to remove them from Chrome, Edge and the spec — and even then a deprecation trial and enterprise policy gave developers extra time to make changes.
In fact, finally removing mutation events from all the browsers is one of the focus areas in Interop 2025; Firefox 140 removed them in June 2025, 13 years after adding a bug for the problems they cause, and Safari 26 will finally drop support too. One difference: XSLT would be the first time a feature marked as Baseline widely available gets removed.
Perhaps due to what the Chrome team views as much lower usage and the numerous security questions raised by Mozilla, the removal of XSLT might happen more quickly. There are already pull requests to remove XSLT, not just from Chrome (while adding a message suggesting users search the Chrome web store for an extension that can handle XSLT), but from the HTML spec too (the DOM spec will also need to be changed, as will the MDN documentation).
That doesn’t mean a decision has been made, though. The WHATWG process has four stages for adding new web platform features; they don’t fit removing features quite as well, but at the time of writing, the XSLT proposal was still marked as stage one.
“We see that there are bugs, and that these bugs wind up affecting people. It’s code that gets shipped in the browser, and could we shut it down? It’s a reasonable question [ for browser vendors], and it’s not a foregone conclusion.”
– Brian Kardell, Igalia developer
The pull requests are actually part of that process, Igalia developer advocate Brian Kardell explained. “In order to be stage two, you need to have rough consensus and a PR we can discuss, ideally, with a prototype and at least one engine, and that’s what they’re doing,” he said. “They’re working on a PR that we can discuss. They’re working on a prototype, and they’re listening to this feedback.”
Aside from the mud-slinging, he characterized the situation as “a good mess”. “It’s happening early in the process, the right people are speaking up, Google is doing the right things, they have a process that’s going to help them discover where the problems are and the public is involved.”
“It’s a reasonable thing for the browsers to ask this question,” Kardell continued, “and it’s a reasonable thing for them to say ‘we don’t see any data that there’s widespread use’. We see that there are bugs, and that these bugs wind up affecting people. It’s code that gets shipped in the browser, and could we shut it down? It’s a reasonable question, and it’s not a foregone conclusion.”
At least three Blink API owners (the not-very-public group that oversees Chrome governance) need to sign off on all new and removed features and the Blink principles include aligning with other browsers as well as standards.
“It’s a universal position that XSLT is mainly pain,” Kardell told us. While he doesn’t expect all traces of XSLT to disappear from browsers without any support for developers and existing sites, he doesn’t expect significant investment either.
As well as the polyfill, Chrome can test the situation by putting XSLT behind a runtime flag that leaves the code for it in the browser, but turns it off for a percentage of users, so that results can be tracked.
Browsers can also treat RSS feeds as a special case, perhaps using similar techniques to the accessible reader mode in browsers that automatically reformats pages, Kardell suggested. “If you were building a pod catcher, you would just have a standard way to display your podcasts. If you were building an RSS reader, you would just have a standard way to display your RSS. You wouldn’t necessarily use the XSL. So, we could just do that at a minimum and protect the normies from bumping into it all the time.”
The feedback from other implementers has been “cautiously supportive,” as WebKit’s Anne van Kesteren put it (suggesting that WebKit would “probably wait for one implementation to fully remove support” unless there was a successful reverse origin trial). Not surprisingly, Firefox is also supportive but possibly more cautious: Mozilla’s Olli Pettay agreed that it was “definitely worth trying”.
“Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT.”
– Simon Pieters, Firefox web standards engineer
Because the discussion about XSLT has become so contentious, none of the browser teams wanted to talk to The New Stack about the details.
Mozilla told us “our commitment is to ensure web technologies remain reliable and compatible for users and it isn’t far from earlier discussions in WHATWG” and pointed to the latest comment by Firefox web standards engineer Simon Pieters. “Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium’s effort to find out if it would be web-compatible to remove support. If it turns out that it’s not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance.” That would include replacing the current XSLT implementation in Firefox.
Microsoft also declined to comment, but Edge doesn’t always adopt changes in Chromium if it doesn’t agree that they benefit browser users.
Getting XSLT up to Date Isn’t Enough
One of the arguments for dropping XSLT from the browser isn’t accurate; libxslt isn’t an abandoned or unmaintained project. It has a new maintainer in Ivan Chavero, who told The New Stack, “Once I fully understand the Gnome workflow, I plan to stabilize the project and close all the issues (about 33). After resolving them, I’m planning on implementing XSLT 3.0 to bring the library to the current standards.”
He’s too new to the codebase to be able to estimate how much work that will take (another XSLT 3 engine has been in development for two years and still isn’t finished) but added that “part of the plan is to collaborate also with the libxml2 folks to implement the XML 3.0 standard.”
While that would obviously be useful for browsers, Chavero is focusing on software developers who already use libxslt to build tools like Inkscape – especially so that the open source community can build alternatives to commercial software for working with government data, like tax returns and invoices that increasingly require XML and XSLT.
“In Mexico, we need these and other free and open technologies to maintain our digital sovereignty…”
– Ivan Chavero, new libxslt maintainer
“The Mexican SAT (Mexico’s equivalent of the United States IRS) uses XML to serialize tax information for each transaction and XSLT for transformations needed to check data integrity,” he explained. “In Mexico, we need these and other free and open technologies to maintain our digital sovereignty, especially in a time when everything of importance is managed by computers.”
Similarly, Poland is currently moving to mandatory e-invoices using a required XML schema for both businesses and taxpayers; XSLT would be ideal for transforming that into your preferred invoice format — and if XSLT stays built into the browser, it’s easier to make a web app that does that.
A more actively developed project that supports the latest standard is likely to be more secure and sounds like an appealing prospect, but while Chavero plans to follow the Gnome security guidelines for libxslt, libxml2 still marks itself as being “badly tested, written in a memory-unsafe language and full of security bugs” and doesn’t accept disclosure deadlines for vulnerabilities. The project is also considering changing its licence from MIT to GPL, or adding a paid commercial option, either of which would be problematic for browsers (and Linux distros, all of which rely on the library).
The Firefox team has other security concerns, including the fact that XSLT is usually implemented in C or C++ and the architecture of the way it’s integrated into browsers.
“If browsers could, they would replace all the C with something better, something truly memory safe,” Kardell noted.
But the current fallback of using a polyfill that compiles libxslt into Wasm means that not all of those will be addressed anyway (although moving the code into user space means it’s not as useful for attacking the rest of the browsers). That may be why engineers from Google and Apple have been showing interest in contributing to these libraries — as well as making sure they have an avenue for contributing the patches they need.
“We’ve granted GNOME accounts to several engineers from both Google and Apple specifically for access to libxml2 and/or libxslt, most recently [at the end of August],” Michael Catanzaro of the GNOME Release Team wrote in the license discussion. “Some are focused on downstream, but some seem interested in helping with upstream. Thus far they’ve only posted patches in the libxslt issue tracker, but I believe they are willing to contribute to libxml2 as well.”
Depending on external projects isn’t a new thing for browsers, but it’s usually done with more explicit cooperation with those projects than has been the case with libxml2 and libxslt; and if the current drama results in more investment and a better relationship with projects they depend on, that would be a helpful development.
While technology companies like Google and Apple have a great deal of money, the budgets for their browser teams can be surprisingly limited.
Several browsers use the Skia 2D graphics library and the way browsers now support PDF is with a shared built-in extension, PDF.js. In fact, to reduce the effort required to implement Temporal (a comprehensively large feature that covers dates, times, calendars and timezones), Google’s V8 team is currently working with the Boa JavaScript engine to use a Temporal Rust crate developed by Boa.
Incidentally, this is also a good reminder that while technology companies like Google and Apple have a great deal of money, the budgets for their browser teams can be surprisingly limited: Google has only three people working on Temporal, and Apple has only one engineer.
As a memory-safe language, Rust would be a good choice for implementing XSLT with fewer security issues — and there are already open source projects in development.Xee is an open source XML Execution Engine with an (incomplete and “far from ready”) XSLT 3 implementation, while the newer Xrust already has a complete XLT 1 implementation, though it’s not compatible with current client-side XSLT, because it uses the XSLT 3 data model and has some features from XSLT 2 and 3, with more in development. Neither is currently planning legacy XSLT 1 support for existing browser pages, although this could be handled with versioning.
Building on a more up-to-date library for XSLT would still be a lot of work for a feature that browsers and standards groups view as not widely used. Even at W3C, XSLT has been reduced to a community group from the previous working group; many of the same people are involved, but community groups don’t have the same standing and don’t usually produce standards.
But what dropping client-side XSLT loses is the potential for what developers could achieve with XSLT 3: a powerful, declarative alternative to JavaScript for client-side scripting and application development in browsers, that could match what developers are currently achieving with XSLT outside browsers.
Even XSLT 1 is a very clever way of comparing or even updating HTML code, because it’s so good at making complex selections. <xsl:template match=”//blockquote/*[not(local-name() = ’em’)]/text()”> will find any <blockquote> in your code that has a child node that’s anything other than <em> and that also contains text, and match that text so you can extract or reuse it. These kinds of expressions also make it easy to compare XML documents and create a record of what’s changed and when.
“XSLT 3.0 feels as if it was made expressly with the modern web in mind; there is so much more potential there.”
– Noah Marples, an XSLT developer
That’s trivial to write in XSLT from 1999, but “modern JavaScript and CSS still could not as easily select and parse out the above selector in a single operation,” explained Noah Marples, an XSLT developer who has been recreating the Flash Uniqlock with modern web technologies. “It took CSS 27 years to get :has() formalized into all major browsers, to accomplish selections that have been trivial with the first version of XPath from 1998.”
“XSLT 3.0 feels as if it was made expressly with the modern web in mind; there is so much more potential there,” Marples pointed out. Extracting data from a web app built with JSON usually means reverse-engineering API calls, reconstructing state and dealing with application logic. Being able to parse JSON directly would be very useful for client-side code that could convert JSON to useful HTML without needing to reconstitute it back into a JavaScript object.
Adding XSLT 3 to browsers would be “a huge game changer in terms of how one writes code to parse and manipulate data: JSON, XML or HTML,” Marples suggested. “Basically, there isn’t much you can’t do with it when it comes to drilling down into data, extracting data or formatting data to display in a particular way — quickly.”
The rise of generative AI makes client-side XSLT even more useful, Jean Paoli (now CEO of AI company Docugami) told us. “Removing XSLT now is tone-deaf: there is a wide industry consensus that XML is today, in 2025, the most efficient language to interact with LLMs (most frontier models recommend to their millions of customers to use XML-formatted prompts). We need more (not less) ways to transform XML in the browser.”
A Question of Priorities
0.001% of a very large number is still a very large number: potentially tens of millions of webpages rely on XSLT in the browser. But it’s also a very small number compared to the number of pages that don’t; the developers who rely on XSLT in the browser and are speaking up — asking for it to be improved rather than removed — may represent a passionate and vocal minority.
“Everything that happens in the web platform comes down to some kind of cost-benefit analysis, because you have limited resources,” Kardell pointed out. “People who are spending two or three days triaging and fixing bugs, or maybe it’s two or three weeks, aren’t working on stuff that is more important. And I’m not saying it’s right or wrong; in fact, I think oftentimes it’s wrong. We don’t have great ways of prioritizing this stuff.”
In the end, the question of whether to support client-side XSLT isn’t just about one out-of-date, less commonly used feature, even though that’s clearly the reason why Firefox raised the question and Google made its proposal. It needs to be decided on its own technical merits, rather than become a football in a wider debate about the governance of the web platform.
“The web community has gladly kept the issue of browser funding swept far under the rug for two decades…”
– Robin Berjon, technologist and former HTML spec editor
But it’s also impossible to ignore the outsized impact that Google funding so much of it, directly or indirectly, has on choices all the browsers make about prioritizing features — especially the ones that don’t fit into current development fashion and hype, whether that’s XSLT or SVG or MathML.
“The web community has gladly kept the issue of browser funding swept far under the rug for two decades, even as issues and lawsuits accumulated, and browser engine diversity plunged,” Robin Berjon, a technologist working on issues of governance and a former editor of the HTML spec, noted. “We are long overdue for a serious rethink of the question.”
