I'd consider JS and WASM quite a bit more risky from a security standpoint, which is why everyone should refuse loading and executing those by default.
Securing an XSLT 3.0 implementation would be much easier.
Should we remove XSLT from the web platform?
21–30 of 99 posts
Re: Should we remove XSLT from the web platform?
#22[deleted]
Re: Should we remove XSLT from the web platform?
#23Earlier quoted context omitted.
Why shouldn't people be overly emotional? Humans are emotional - and that's a good thing. This change would make people sad because things they like would stop working. It would cause them stress because they would have to work hard to fix or replace things. It would cause them anger because some unaccountable people would be making decisions without considering them. It would make them afraid that those same people…
It’s ok to have emotions, even as an adult, we all have feelings. However, it’s important to be kind to other humans and to treat humans with respect. Even on the internet, even when people are proposing removing features from a browser. Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have. I think this is especially true on GitHub whe…
> However, it’s important to be kind to other humans and to treat humans with respect.
Very true. But why is that argument never deployed against the bullies?
Chrome's developers say "We want to do X". People say "No, please don't." Chrome says "I'm not going to respect your wishes."
Where's the equality in that?
> Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have.
The same is also true of people making those proposals. Chrome devs should know (from bitter experience) that releasing a high-handed statement, studiously ignoring all dissent, and then swinging the ban-hammer is going to lead to ill-will.
Again, why isn't anyone calling for them to be more calm and respectful of the people they're hurting?
> I wouldn’t want to wish that on anyone.
I've been on the receiving end and - yes - it sucks. But given that they know these proposals would be contentious, why didn't they approach this in a more respectful and collaborative manner?
Re: Should we remove XSLT from the web platform?
#24The problem with browsers is that they rely on other standards. If a browser needs to maintain backward compatibility and requires an evolving standard that ALSO requires backward compatibility, this acts like a multiplier on implementation complexity. This also means it becomes increasingly difficult to spin up a new browser engine, and the fewer of those there are, the easier it is for the big ones to just add what…
XSLT adds ~100k lines of specialized code to browser engines with near-zero telemetry usage (<0.01% of page loads), making it a prime example of the maintenance burden vs. utility problem you're describing.
Re: Should we remove XSLT from the web platform?
#25Earlier quoted context omitted.
When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required
Why can’t things remain backwards compatible forever? In the 35 years that the Web has existed, browsers have come pretty damn close to meeting that standard. The one huge exception is the removal of plugin support around 2015, and the concomitant death of Flash and Java applets. There were also some major browser-specific APIs that got killed off, like ActiveX and NaCl. But when it comes to standardized, browser-nat…
> Why can’t things remain backwards compatible forever?
I already said why:
> The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
If you read the GitHub issue that this submission links to, the issue points out security vulnerabilities and links to:
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
— https://www.offensivecon.org/speakers/2025/ivan-fratric.html
Re: Should we remove XSLT from the web platform?
#26Why is it always Google employees that want to kill things?
Re: Should we remove XSLT from the web platform?
#27Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for k…
The wikipedia api has an option where you can add an xslt stylesheet to its output. When i was young and stupid and learning to program i made an xslt stylesheet to extract dictionary definitions from the api. It was meant to be combined with a bookmarklet that when you double clicked a word opened it in an iframe. It was terrible, but i was so proud of it at the time. It seems like it stopped working at some point,…
> It was terrible, but i was so proud of it at the time.
Terrible why? Bookmarklets and XSLT (and things like Greasemonkey userscripts) were some of the things that made the web more "read-write" in the '00s: anyone could remix web content however they saw fit, optimizing it for their personal use-cases, and often attracted kids and "normies" to coding.
Even today, they can be used to do stuff that most people find magical. Unfortunately they are unfashionable, so they're slowly getting strangled by the big players who want to have all the control all the time.
Re: Should we remove XSLT from the web platform?
#28The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of…
Why shouldn't people be overly emotional? Humans are emotional - and that's a good thing. This change would make people sad because things they like would stop working. It would cause them stress because they would have to work hard to fix or replace things. It would cause them anger because some unaccountable people would be making decisions without considering them. It would make them afraid that those same people…
> Why shouldn't people be overly emotional?
By definition overly emotional is bad – that’s what separates “overly emotional” from just “emotional”.
Regardless, having emotions is not the problem, lashing out at others because of those emotions is the problem.
> These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback.
The person you are responding to said:
> we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
Why are you misrepresenting this as “it will make me sad”?
Re: Should we remove XSLT from the web platform?
#29Obligatory xkcd: https://xkcd.com/1172/
I love XKCD, but this particular strip has been used to justify all sorts of arbitrary and negative decisions. XSLT support is not a bug.
Re: Should we remove XSLT from the web platform?
#30The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of…
Personally I've found googles responses to be very rude; they've asked for feedback and people have come back saying "We're still using this, please don't just remove it" and despite that they seem to be completely uncompromising on removing it without any adjustments like shipping the wasm polyfill instead of native code.
It kind of baffles me that they could even consider this, maybe I'm just naiive but the webs greatest strength has always been it's backwards compatibility; I can fire a page up written 30 years ago and it still renders (assuming it wasn't built in flash lol). Breaking the user experience like this and saying "well the owners need to update their site" doesn't work - a lot of these pages won't be actively maintained or under the control of someone who can make changes.