4 ms·

Blame Apple and Mozilla, too, then. They all agreed to remove it. They all agreed because XSLT is extremely unpopular and worse than JS in every way. Performan

Blame Apple and Mozilla, too, then. They all agreed to remove it. They all agreed because XSLT is extremely unpopular and worse than JS in every way. Performance/bloat? Worse. Security? MUCH worse. Language design? Unimaginably worse. EDIT: I wrote thousands of lines of XSLT circa 2005. I'm grateful that I'll never do that again.

stickfigure 11mo ago
This is only repeated by people who have never used it. XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).
- mschuster91 11mo ago
  I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty. Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!
  - stickfigure 11mo ago
    It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams... I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every popular CI system for "YAML is not a programming language". That doesn't mean that XML isn't useful. Just not as a programming language.
    - mschuster91 11mo ago
      > It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams... npm isn't even a build tool, it's a package manager and at that it's actually gotten quite decent - the fact that the JS ecosystem at large doesn't give a fuck about respecting semantic versioning or keeps reinventing the wheel or that NodeJS / JavaScript itself lacks a decent standard library aren't faults of npm ;) Maven and Gradle in contrast are one-stop-shops, both build orchestrators and dependency managers. As for ant, oh hell yes I'm aware of that. The most horrid build system I encountered in my decade worth of tenure as "the guy who can figure out pretty much any nuclear submarine project (aka, only surfaces every few years after everyone working on it departed)" involved Gradle, which then orchestrated Maven and Ant, oh and the project was built on a Jenkins that was half DSL, half clicked together in the web UI, and the runner that executed the builds was a manually set up, "organically grown" server. That one was a holy damn mess to understand, unwind, clean up and migrate to Gitlab. > look at pretty much every popular CI system for "YAML is not a programming language". Oh yes... I only had the misfortune of having to code for Github Actions once in my life time, it's utter fucking madness compared to GitLab.
    - dfabulich 11mo ago
      But, that's what XSL is! XSL is a Turing-complete programming language in XML for processing XML documents. Being in XML is a big part of what makes XSL so awful to write.
      - stickfigure 11mo ago
        XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages. Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.
- garethrowlands 11mo ago
  I used to use XSLT a lot, though it was a while ago. You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code. Do you have a particular example where you think Javascript might be more verbose than XSLT?
- imtringued 11mo ago
  Who is transforming XML documents on the web? Most people produce HTML to begin with, so XSLT is a solution seeking a problem. If you really insist, you could just use XSLT via server side rendering.
silon42 11mo ago
How is it worse than JS? It's a different thing...
dfox 11mo ago
> Security? MUCH worse. Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense. Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)
- exasperaited 11mo ago
  Are the security concerns not about libxslt, rather than XSLT?
  - righthand 11mo ago
    They are about libxslt but Mason Freed doesn’t want you to know that. They could contribute a rust project which has already implemented XSLT 1.0 thus matching the browsers. But that would good software engineering and logical.
- dfabulich 11mo ago
  If you would RTFA, they're removing XSLT specifically for security reasons. They provide the following links: https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html > 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://nvd.nist.gov/vuln/detail/CVE-2025-7425 https://nvd.nist.gov/vuln/detail/CVE-2025-7425 https://nvd.nist.gov/vuln/detail/CVE-2022-22834 https://nvd.nist.gov/vuln/detail/CVE-2022-22834 (And, for the record, XSL is Turing-complete. It has xsl:variable, xsl:if, xsl:for-each, and xsl:apply-template function calls.)
righthand 11mo ago
They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons. Only Google is pushing forward and twisting that message.
- JimDabell 11mo ago
  > They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons. Mozilla: > 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. — https://github.com/mozilla/standards-positions/issues/1287#issuecomment-3227145793 https://github.com/mozilla/standards-positions/issues/1287#i... WebKit: > WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support, though if there's a known list of origins that participate in a reverse origin trial we could perhaps participate sooner. — https://github.com/whatwg/html/issues/11523#issuecomment-3149280766 https://github.com/whatwg/html/issues/11523#issuecomment-314... Describing either of those as “they preferred to keep it” is blatantly untrue.
  - righthand 11mo ago
    So you’re choosing to help them spin the lie by cherry picking comments. The Mozilla comment itself ends with: > 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. > If it turns out not to be possible to remove the feature, we’d like to replace our current implementation. The main requirements would be compatibility with existing web content, addressing memory safety security issues, and not regressing performance on non-XSLT content. We’ve seen some interest in sandboxing libxslt, and if something with that shape satisfied our normal production requirements we would ship it. But the only way it’s possible to remove the feature is if you ignore everyone asking you to please not to remove it. Therefor by totally ignoring push back you can then twist Mozilla reps words to mean the only option is to remove it. Similarly with the Webkit comment: > WebKit is cautiously supportive. Both these orgs requested investigation not removal. Both expressed some concern and caution. Google did not, they only ever pushed forward with removing it. Even goong so far as to ignore the followup request to implement XSLT 3.0. No it’s not blatantly untrue. It’s unblatantly misleading. Furthermore I’d say for those specific comments, “go ahead and remove it”, the inverse is blatantly untrue.
cxr 11mo ago
> They all agreed to remove it. All those people suck, too. Were you counting on a different response? > XSLT is extremely unpopular and worse than JS in every way This isn't a quorum of folks torpedoing a proposed standard. This is a decades-old stable spec and an established part of the Web platform, and welching on their end of the deal will break things, contra "Don't break the Web".
- shadowgovt 11mo ago
  You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.
  - cxr 11mo ago
    Do you still beat your wife? <https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife? https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife?>
    - shadowgovt 11mo ago
      I don't think that applies here (especially since I didn't even ask a question). "I'm sad it's going away in the client!" "So move it to the server, and the end-user will get essentially the same experience." Am I missing something here?
      - cxr 11mo ago
        > especially since I didn't even ask a question Oh, that's the operative part? Accept my apologies. What I meant to say is, "I can see that you're deeply, deeply concerned about being able to continue beating your wife. I think you should reconsider your position on this matter." No question mark, see? So I should be good now. > Am I missing something here? Probably not. People who engage in the sort of underhandedness linked to above generally don't do it without knowing that they're doing it. They're not missing anything. It's deliberate. So, too, I would guess, is the case with you—particularly since your current reply is now employing another familiar underhanded rhetorical move. Familiar because I already called it out within the same comment section: > The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke. <https://news.ycombinator.com/item?id=45824392 https://news.ycombinator.com/item?id=45824392>

stickfigure 11mo ago

This is only repeated by people who have never used it. XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).

mschuster91 11mo ago
I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty. Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!
- stickfigure 11mo ago
  It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams... I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every popular CI system for "YAML is not a programming language". That doesn't mean that XML isn't useful. Just not as a programming language.
  - mschuster91 11mo ago
    > It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams... npm isn't even a build tool, it's a package manager and at that it's actually gotten quite decent - the fact that the JS ecosystem at large doesn't give a fuck about respecting semantic versioning or keeps reinventing the wheel or that NodeJS / JavaScript itself lacks a decent standard library aren't faults of npm ;) Maven and Gradle in contrast are one-stop-shops, both build orchestrators and dependency managers. As for ant, oh hell yes I'm aware of that. The most horrid build system I encountered in my decade worth of tenure as "the guy who can figure out pretty much any nuclear submarine project (aka, only surfaces every few years after everyone working on it departed)" involved Gradle, which then orchestrated Maven and Ant, oh and the project was built on a Jenkins that was half DSL, half clicked together in the web UI, and the runner that executed the builds was a manually set up, "organically grown" server. That one was a holy damn mess to understand, unwind, clean up and migrate to Gitlab. > look at pretty much every popular CI system for "YAML is not a programming language". Oh yes... I only had the misfortune of having to code for Github Actions once in my life time, it's utter fucking madness compared to GitLab.
  - dfabulich 11mo ago
    But, that's what XSL is! XSL is a Turing-complete programming language in XML for processing XML documents. Being in XML is a big part of what makes XSL so awful to write.
    - stickfigure 11mo ago
      XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages. Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.
garethrowlands 11mo ago
I used to use XSLT a lot, though it was a while ago. You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code. Do you have a particular example where you think Javascript might be more verbose than XSLT?
imtringued 11mo ago
Who is transforming XML documents on the web? Most people produce HTML to begin with, so XSLT is a solution seeking a problem. If you really insist, you could just use XSLT via server side rendering.

silon42 11mo ago

How is it worse than JS? It's a different thing...

dfox 11mo ago

> Security? MUCH worse. Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense. Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)

exasperaited 11mo ago
Are the security concerns not about libxslt, rather than XSLT?
- righthand 11mo ago
  They are about libxslt but Mason Freed doesn’t want you to know that. They could contribute a rust project which has already implemented XSLT 1.0 thus matching the browsers. But that would good software engineering and logical.
dfabulich 11mo ago
If you would RTFA, they're removing XSLT specifically for security reasons. They provide the following links: https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html > 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://nvd.nist.gov/vuln/detail/CVE-2025-7425 https://nvd.nist.gov/vuln/detail/CVE-2025-7425 https://nvd.nist.gov/vuln/detail/CVE-2022-22834 https://nvd.nist.gov/vuln/detail/CVE-2022-22834 (And, for the record, XSL is Turing-complete. It has xsl:variable, xsl:if, xsl:for-each, and xsl:apply-template function calls.)

righthand 11mo ago

They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons. Only Google is pushing forward and twisting that message.

JimDabell 11mo ago
> They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons. Mozilla: > 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. — https://github.com/mozilla/standards-positions/issues/1287#issuecomment-3227145793 https://github.com/mozilla/standards-positions/issues/1287#i... WebKit: > WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support, though if there's a known list of origins that participate in a reverse origin trial we could perhaps participate sooner. — https://github.com/whatwg/html/issues/11523#issuecomment-3149280766 https://github.com/whatwg/html/issues/11523#issuecomment-314... Describing either of those as “they preferred to keep it” is blatantly untrue.
- righthand 11mo ago
  So you’re choosing to help them spin the lie by cherry picking comments. The Mozilla comment itself ends with: > 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. > If it turns out not to be possible to remove the feature, we’d like to replace our current implementation. The main requirements would be compatibility with existing web content, addressing memory safety security issues, and not regressing performance on non-XSLT content. We’ve seen some interest in sandboxing libxslt, and if something with that shape satisfied our normal production requirements we would ship it. But the only way it’s possible to remove the feature is if you ignore everyone asking you to please not to remove it. Therefor by totally ignoring push back you can then twist Mozilla reps words to mean the only option is to remove it. Similarly with the Webkit comment: > WebKit is cautiously supportive. Both these orgs requested investigation not removal. Both expressed some concern and caution. Google did not, they only ever pushed forward with removing it. Even goong so far as to ignore the followup request to implement XSLT 3.0. No it’s not blatantly untrue. It’s unblatantly misleading. Furthermore I’d say for those specific comments, “go ahead and remove it”, the inverse is blatantly untrue.

cxr 11mo ago

> They all agreed to remove it. All those people suck, too. Were you counting on a different response? > XSLT is extremely unpopular and worse than JS in every way This isn't a quorum of folks torpedoing a proposed standard. This is a decades-old stable spec and an established part of the Web platform, and welching on their end of the deal will break things, contra "Don't break the Web".

shadowgovt 11mo ago
You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.
- cxr 11mo ago
  Do you still beat your wife? <https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife? https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife?>
  - shadowgovt 11mo ago
    I don't think that applies here (especially since I didn't even ask a question). "I'm sad it's going away in the client!" "So move it to the server, and the end-user will get essentially the same experience." Am I missing something here?
    - cxr 11mo ago
      > especially since I didn't even ask a question Oh, that's the operative part? Accept my apologies. What I meant to say is, "I can see that you're deeply, deeply concerned about being able to continue beating your wife. I think you should reconsider your position on this matter." No question mark, see? So I should be good now. > Am I missing something here? Probably not. People who engage in the sort of underhandedness linked to above generally don't do it without knowing that they're doing it. They're not missing anything. It's deliberate. So, too, I would guess, is the case with you—particularly since your current reply is now employing another familiar underhanded rhetorical move. Familiar because I already called it out within the same comment section: > The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke. <https://news.ycombinator.com/item?id=45824392 https://news.ycombinator.com/item?id=45824392>