Posted by CharlesW 11/1/2025
There have been other removals, but few of them were of even specified features, and I don’t think any of them have been universally available. One of the closest might be showModalDialog <https://web.archive.org/web/20140401014356/http://dev.opera....>, but I gather mobile browsers never supported it anyway, and it was a really problematic feature from an implementation perspective too. You could argue Mutation Events from ~2011 qualifies¹; it was supplanted by Mutation Observers within two years, yet hung around for over a decade before being removed. As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway.
And so here they are now planning to remove a well-entrenched (if not especially commonly used) feature against the clearly-expressed will of the actual developers, in a one year time frame.
—⁂—
¹ I choose to disqualify Mutation Events because no one ever finished their implementation: WebKit heritage never did DOMAttrModified, Gecko/Trident heritage never did DOMNodeInsertedIntoDocument or DOMNodeRemovedFromDocument. Flimsy excuse, probably. If you want to count it, perhaps you’ll agree to consider XSLT the first time a major, standard, baseline-available feature will be removed?
I think this sets a concerning precedent for future deprecations, where parts of the web platform are rugpulled from developers because it's convenient for the browser vendors.
The precedent was already set when they tried to remove alert/prompt. See https://dev.to/richharris/stay-alert-d and https://css-tricks.com/choice-words-about-the-upcoming-depre...
Only a large public outcry stopped them, barely.
To quote from the first link:
--- start quote ---
Meanwhile, we don't seem to be learning from the past. If alert is fair game for removal, then so is every API we add to the platform if the web's future stewards deem it harmful.
Given Chrome's near-monopoly control of the browser market, I'm genuinely concerned about what this all means for the future of the web. An ad company shouldn't have this much influence over something that belongs to all of us. I don't know how to fix the standards process so that it's more representative of the diversity of the web's stakeholders, but I'm increasingly convinced that we need to figure it out.
--- end quote ---
These aren't horrible formats or standards. XSLT is actually somewhat elegant.
Why? Answer this question: how can you use XML in a way that does not create horrible security vulnerabilities?
I know the answer, but it is extremely nontrivial, and highly dependent on which programming language, library, and sometimes even which library function you use. The fact that there's no easy way to use XML without creating a security footgun is reason enough to avoid it.
1. The entity bomb. An entity that expands to another, which expands to another, and so on so that the final result is enormous. This is an issue of the implementation: if it expands the entities eagerly then the bomb will work. But it it first examines them and checks how much space they require it can safely reject the document if it exceeds some configurable limit. As far as I know this has been fixed in all XML processors.
2. An entity can resolve to a local or remote file. First, this is a feature. Imagine a large collection of bibliographic records, each in a separate file. A publication can provide its list of references as a list of entities that refer to these files using entities. (There is an RFC that uses this as an example.) And, of course, we need both local and remote entities.
But, of course, if your XML comes from an untrusted source and you read it with this feature enabled this can lead to obvious disasters. Yet it is not a vulnerability of XML. Again, as far as I know all XML processors can disable access to local or remote entities.
If you removed support for anything that has/could have security vulnerabilities you would remove everything.
There's plenty of reasons to criticize XML, and plenty more to criticize XSLT. But security being the one you call out feels at least moderately disingenuous. It's a criticism of the library, not the standard or the format.
XML is so complex that a 100% bug-free compliant library is inherently insecure, and the vulnerability is a "user is holding it wrong" siutation, they should have disabled specific XML features etc. That means XML is an inherently much more insecure format.
There's a reason there's name for vulnerabilities like XML External Entity (XXE) injection [1] and they're named after XML, and not "bug in lib/software X". JSON and most other data formats don't have that.
Let alone JavaScript…
Yes. Just like we don't have Flash everywhere or ActiveX. Good riddance to them and to XSLT and, fingers crossed, XML in the future.
I feel like there is a bit of a no true scotsman to this.
XSLT was always kind of on the side. If FTP or flash weren't part of the web platform than i dont know that xslt is either. Flash might not be "standard" but it certainly had more users in its heyday than xslt ever did.
Does removal of tls 1.1 count here? Its all kind of a matter of definitions.
Personally i always thought the <keygen> tag was really cool.
FTP was never integrated: it just so happened that some platforms shipped a protocol handler for it, and some browsers included an FTP protocol handler themselves. But I don’t believe you could ever, say, fetch("ftp://…").
Flash, like applets, was even more clearly not part of the web platform. It was a popular third-party extension that you had to go out of your way to install… or wait for it to be installed by some shady installer Adobe paid off. Though I have a vague feeling Chrome shipped with Flash at some point? I don’t remember all the history any more, this is a long time ago.
Older versions of TLS is definitely a more interesting case. It’s a different kind of feature, but… yeah, I might consider it.
<keygen> was an interesting concept that in practice went nowhere.
I never tried, but i believe the relavent spec said it should work, until it was deprecated and removed from the standard https://github.com/whatwg/fetch/pull/1166
With flash - that might all be true, but there was a time when many websites required it. It might not have been a de jure standard but it was a de facto standard. To the point where a browser not supporting it was considered broken. Apple refusing to support it was incredibly controversial at the time.
On the other… I’m still a bit uncomfortable with the proposed change because it reads as another example of Google unilaterally dictating the future of the web, which I’ve never liked or supported.
Feeling quite conflicted.
This change definitely feels like moving a (tiny) step into the direction of turning the Web platform into something akin to the Android dev experience.
I mean, presumably they have the usage stats… except that plenty of enterprises deployed XSLT apps back in the day - it was on a massive portion of the job ads I was looking at in 2000 to 2002 - and I’d bet a chunk of those legacy systems are still running. I’d also bet a good chunk of those systems are running in the sort of orgs that won’t allow submission of telemetry to Google, so Google’s usage stats underreport real world usage.
To me it looks like zero effort has been made to engage with Mozilla, Apple, etc., on the right way forward here - just Google high-handedly making moves and abusing their position as per usual.
What would make you think that? The submission links prominently to the whatwg proposal github issue, which is the forum where that engagement would happen. It explicitly deep-links to Mozilla's and Apple's posts in that thread. It has the usage stats that you just presume exist.
It's like you just made up a scenario and posted it as facts with zero effort to verify any of it.
The XML proponents lost this fight a long time ago. Without continued development, the user base shriveled up. Now that no one uses it, the runtimes are looking to cut dead weight.
I disagree with the pivot (RIP noscript) but it's not Google making this move unilaterally. It's been in the works for a long time.
I’m not a Chrome dev but I think they have decent reasons for going this way.
<blink> was never universal, contrary to popular impression: <https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20bl...>, it was only ever supported by Netscape/Gecko/Presto, never Trident/WebKit. Part of the joke of Blink is that it never supported <blink>.
> Netscape only agreed to remove the blink tag from their browser if Microsoft agreed to get rid of the marquee tag in theirs during an HTML ERB meeting in February 1996.
Fun times. Both essentially accusing the other of having a dumb tag.
[1] For example: https://www.nagpuruniversity.ac.in/
Indian Rail <https://www.indianrail.gov.in/> has one containing the chart from a mid-2024 train accident, an invitation to contribute a recording of the national anthem from 2021, and a link to parcel booking. Oh, and “NEW!” animated GIFs between the three items.
That's gotta be the second most popular web design quirk. Haha
Flash was the web technology.
In 19th century Russia there was a thinker, N. F. Fedorov, who wanted to revive all dead people. He saw it as the ultimate goal of humanity. (He worked in a library, a very telling occupation. He spent most of what he earned to support others.) We do not know how to revive dead people or if we can do that at all; but we certainly can revive old tech or just not let it die.
Of course, this job is not for everyone. We cannot count on the richest, apparently, they're too busy getting richer. This is a job for monks.
The browser vendors are arguing XSLT is neither good - it's adoption has always been lacking because of complexity and has now become a niche technology because better alternatives exist - nor working, see the mentioned security and maintenance issues. I think they have a good point there.
I think it is because nobody, excepts a handful of people around the world, feels the need to use XSLT in lieu of CSS. Hence, CSS has evolved over time while XSLT has not.
This is how the world works: technology advances and old things become obsolete over time.
XSLT isn't about styling documents, but is more like ETL (Extract, Transform, and Load)
CSS and XSL-FO are entirely different concepts
If it were true, everyone would have used this instead of CSS.
And I know here on HN there are people that for whatever reason like it. I don't.
XSLT lets you build completely static websites without having to use copy paste or a static website generator to handle the common stuff like menus.
How many people ever do this?
REPO: https://github.com/gregabbott/skip
DEMO: https://gregabbott.pages.dev/skip
(^ View Source: 2 lines of XML around a .md file)
https://web.archive.org/web/20140101011304/http://www.skeche...
They don't anymore. It was a pretty strange design.
http://www.blogabond.com/xsl/vistacular.xml
The upside is that the entire html page is content. I defy google to not figure out what to index here:
view-source:http://www.blogabond.com/xsl/vistacular.xml
The downside is everything else about the experience. Hence my 15 years of not bothering to implement it in a usable way.
Easy: ignore due to no content-type header.
I’m confused by your comment. My XSLT stylesheets are like this:
``` <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> ```
Any pointers to tech that did this, if it was a common case?
(I'm also doing this currently; I need to prepare a sort of an annotated patch to an XML document, so I concocted a notation that describes edits and use it to generate both the documentation that highlights differences and also the patch itself; the patch comes out as XSLT.)
The question isn't whether or not you use XSLT yourself, it's whether you use a different feature that could be deemed unprofitable and slammed on the chopping block. And therefore a question of whether it wouldn't be better for everyone for this work to be publicly funded instead.
Why would the public sector feel bound to support it as opposed to pivot in the same direction the winds are blowing?
Outside the idiocy of this particular administration in the US, gov is pivoting toward more commercial norms (with compliance/etc for gov cloud and etc compliance).
The underlying axiom is the Pareto principle - that you get 80% of the benefit from the first 20% of the work, and getting the last 20% of the benefit takes up 80% of the work. The private sector will stop funding after the first 80% of benefit (it's not profitable to chase the last 20%) but the public sector is usually mandated to support everybody so it is indeed required to put in that extra effort.
It is true that public bodies are less concerned with profitability, which changes how they make decisions around deprecations and removals, but being cost-effective is still important for them, especially when budgets are low and need is high. In situations like that, it's not uncommon for, say, a service to get cut so that funding can be reallocated elsewhere where it's more needed.
I don't think publicly funding this sort of work would necessarily significantly change the equation here. The costs of XSLT are relatively high because of its complexity and the natural security risks that arise from that complexity. Meanwhile, it is very rarely used, and where it is used, there are better alternatives (generally loading a sandboxed library rather than using the built-in tooling).
But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish).
XSLT is currently the only way to make feeds into something that can still be viewed.
I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO).
I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/
You can see it in action on an RSS feed here (served as real XML, not HTML): https://www.fileformat.info/news/rss.xml
Now, do you need XSLT’s capabilities in the browser? Their stats say no one’s really using it.
I suppose we can expect support for XML to be dropped soon as well, since libxml2 maintenance is ending this year.
I don't buy the excuse of low number of users. Google's AMP has abysmal usage numbers, yet they're still maintaining that garbage.
Google has been a net negative for the web, and is directly responsible for the shit show it is today. An entirely expected outcome considering it is steered by corporate interests.
The writing has been on the wall for a long while. Mozilla hasn't stepped up, Google hasn't stepped up, GNOME hasn't stepped up, Oracle hasn't stepped up, etc. Maybe its just a format that once anyone gets involved with, they no longer want to be involved with it any further.
I believe they didn’t just because most of politicians don’t know anything about software.
Being aware of the problems that “governmatization” of open source can bring it still is something I expect to be picked up by countries.
Part of the reason google chrome won the browser wars is because they are willing to make decisions like this. Kitchen sink software is bad software.
Some peple are doing that[1]. It's not a matter of desire, but of the amount of effort and resources required to build and maintain the insanity of the modern web stack.
> Part of the reason google chrome won the browser wars is because they are willing to make decisions like this.
Eh, no. Google Chrome won because it is backed by one of the largest adtech corporations with enough resources and influence to make it happen. They're better at this than Microsoft was with IE, but that's not saying much. When it launched it introduced some interesting and novel features, but it's now nothing but a marketing funnel for Google's services.
People say that, but i don't think that's true. The web stack was always insane, the only difference is its documented now. I think now is a much easier time to build a web browser than the past was.
Not to mention the irony of complaining the web stack is insane while insisting a really difficult to support feature that never saw much use should be kept forever because reasons.
> Eh, no. Google Chrome won because it is backed by one of the largest adtech corporations with enough resources and influence to make it happen
Google won because nobody else really tried.
Firefox has been a dumpster fire of bad management decisions and has reduced itself to basically just copying google's every decision sacraficing any unique identity of its own.
Safari is never going win when it is mac only and apple doesnt seem to fund it very hard.
Most of the rest are just chrome reskins that dont deserve to be called a separate browser.
Maybe something interesting might come out of ladybird. Its still quite early to tell.
Google won because it:
- built on a very solid foundation from the start (it started out as a webkit fork), and was generally a good fast browser. This is the very minor part
- Sabotaged Firefox: https://archive.is/tgIH9
- Heavily promoted and advertised Chrome across all of its properties which included such insignificantly small sites like Google Search and Youtube.
Running an advertising campaign is hardly sabotage
Also, you somehow think that running an exclusive directed ad campaign for Chrome on two most popular sites on the internet is nothing to worry about.
No one should fork chrome and maintain it with XSLT still baked in. Not only would it go unused, it doesn't help anyone wanting to ship XSLT on a site because users would literally have to install a different browser just to see that page.
https://english.stackexchange.com/questions/96582/what-is-th...
Ah yes. That's why Chrome bravely refuses to be a kitchen sink. It only has a small set of available APIs like USB, MIDI, Serial, Sensors (Ambient Light, Gyroscopes etc.), HID, Bluetooth, Barcode detection, Battery Status, Device Memory, Credential Management, three different file APIs, Gamepads, three different background sync APIs, NFC...