4 ms·

Some 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

Some 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 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 keeping it.

omgtehlion 1y ago
> so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.
- conductr 1y ago
  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
  - 3036e4 1y ago
    Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability. I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.
    - shiomiru 1y ago
      > Things can remain backwards compatible forever. This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. Indeed, to me it seems that at some point, you either have to a) freeze the standard b) drop old stuff c) accept that there is no standard and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate. (Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)
      - account42 1y ago
        > This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that. Google is not proposing to reign in that behavior. > a) freeze the standard Yes, or rather new features should become rarer over time. > and with the web as a whole, we are firmly headed towards option c) Which has nothing to do with backwards compatibility but with Chromes appetite for adding new APIs, presumably with exactly this outcome being their goal.
        8NNTt8z3QvLT8tp 1y ago
        Thing is the new APIs added to the web are generally quite well specified with quite good tests. These older legacy APIs sometimes don't even have a standard and almost definitely don't have interoperability (XSLT is an example of one that definitely does not work consistently between WebKit/Blink and Firefox). For a new browser engine adding some of the new APIs is pretty trivial compared to debugging all the nonsense that comes from these kinds of underspecified legacy APIs. Removing XSLT from the spec and existing browsers means new ones don't feel the need to implement it. They don't need to decide which implementation to go with (use libxslt like chromium and webkit and you might match their behaviour but you also get all the same security vulns). Frankly a modern engine could probably get by without handling XML entirely (aka no XHTML document support) and get by just fine but that's a separate discussion.
  - comex 1y ago
    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-native functionality… very little has ever been removed. I would prefer it if I could say the same thing in another 35 years.
    - JimDabell 1y ago
      > 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 https://www.offensivecon.org/speakers/2025/ivan-fratric.html
      - em-bee 1y ago
        for those who have been looking, the actual presentation where they talk about this appears to be here: https://youtu.be/U1kc7fcF5Ao https://youtu.be/U1kc7fcF5Ao
  - account42 1y ago
    If you want to build a stable platform: never.
    - JimDabell 1y ago
      The web platform has repeatedly removed features like this in the past, and it’s the most stable platform in the history of the computer industry.
    - conductr 1y ago
      Absolute stability in that manner is nearly never the goal. Plenty of web standards have been deprecated. They gently push things in a direction and cull what is seen as low value or high risk. I'm not advocating for or against this specific item, just saying we shouldn't perpetually add and bloat future maintenance demands just because we want to support every single thing that's ever been built. We should be able to remove/delete/deprecate in a way that allows reasonable notice to those that could be effected. I'm certainly not advocating for sweeping breaking changes like may be found in some web frameworks, etc. We should expect that browsers move slowly. But there still needs to be some process for culling things IMO.
- pjmlp 1y ago
  Lets remind ourselves that thanks to Google we also did not got WebGL 2.0 Compute, it was too much for Chrome team to spend their resources between WebGL 2.0 Compute and WebGPU. How great that five years later WebGPU is something we can rely on in portable way. /s
bawolff 1y ago
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, i guess browsers are probably more strict with mime types now. https://en.wiktionary.org/w/api.php?action=parse&format=xml&xslt=MediaWiki%3AextractFirst.xsl&prop=text&page=word&lang=en&count=1&showWord=none&audio=none&redirects=on https://en.wiktionary.org/w/api.php?action=parse&format=xml&... Sorry if this is too off topic, it just triggered some memories
- toyg 1y ago
  > 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.
  - bawolff 1y ago
    Sadly i just filed a bug to remove the xslt option from mediawiki's api. By terrible i just mean the code was really hacky. I was a newbie and exploring.
cousin_it 1y ago
Maybe off topic, but I was really inspired by this article and started thinking about other ways to have "in-browser templating". And then realized that the old function document.write() is actually very convenient for this. Tried to write up the pros and cons here: https://vladimirslepnev.me/write https://vladimirslepnev.me/write Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/write https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...

omgtehlion 1y ago

> so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.

conductr 1y ago
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
- 3036e4 1y ago
  Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability. I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.
  - shiomiru 1y ago
    > Things can remain backwards compatible forever. This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. Indeed, to me it seems that at some point, you either have to a) freeze the standard b) drop old stuff c) accept that there is no standard and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate. (Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)
    - account42 1y ago
      > This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that. Google is not proposing to reign in that behavior. > a) freeze the standard Yes, or rather new features should become rarer over time. > and with the web as a whole, we are firmly headed towards option c) Which has nothing to do with backwards compatibility but with Chromes appetite for adding new APIs, presumably with exactly this outcome being their goal.
      - 8NNTt8z3QvLT8tp 1y ago
        Thing is the new APIs added to the web are generally quite well specified with quite good tests. These older legacy APIs sometimes don't even have a standard and almost definitely don't have interoperability (XSLT is an example of one that definitely does not work consistently between WebKit/Blink and Firefox). For a new browser engine adding some of the new APIs is pretty trivial compared to debugging all the nonsense that comes from these kinds of underspecified legacy APIs. Removing XSLT from the spec and existing browsers means new ones don't feel the need to implement it. They don't need to decide which implementation to go with (use libxslt like chromium and webkit and you might match their behaviour but you also get all the same security vulns). Frankly a modern engine could probably get by without handling XML entirely (aka no XHTML document support) and get by just fine but that's a separate discussion.
- comex 1y ago
  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-native functionality… very little has ever been removed. I would prefer it if I could say the same thing in another 35 years.
  - JimDabell 1y ago
    > 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 https://www.offensivecon.org/speakers/2025/ivan-fratric.html
    - em-bee 1y ago
      for those who have been looking, the actual presentation where they talk about this appears to be here: https://youtu.be/U1kc7fcF5Ao https://youtu.be/U1kc7fcF5Ao
- account42 1y ago
  If you want to build a stable platform: never.
  - JimDabell 1y ago
    The web platform has repeatedly removed features like this in the past, and it’s the most stable platform in the history of the computer industry.
  - conductr 1y ago
    Absolute stability in that manner is nearly never the goal. Plenty of web standards have been deprecated. They gently push things in a direction and cull what is seen as low value or high risk. I'm not advocating for or against this specific item, just saying we shouldn't perpetually add and bloat future maintenance demands just because we want to support every single thing that's ever been built. We should be able to remove/delete/deprecate in a way that allows reasonable notice to those that could be effected. I'm certainly not advocating for sweeping breaking changes like may be found in some web frameworks, etc. We should expect that browsers move slowly. But there still needs to be some process for culling things IMO.
pjmlp 1y ago
Lets remind ourselves that thanks to Google we also did not got WebGL 2.0 Compute, it was too much for Chrome team to spend their resources between WebGL 2.0 Compute and WebGPU. How great that five years later WebGPU is something we can rely on in portable way. /s

bawolff 1y ago

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, i guess browsers are probably more strict with mime types now. https://en.wiktionary.org/w/api.php?action=parse&format=xml&xslt=MediaWiki%3AextractFirst.xsl&prop=text&page=word&lang=en&count=1&showWord=none&audio=none&redirects=on https://en.wiktionary.org/w/api.php?action=parse&format=xml&... Sorry if this is too off topic, it just triggered some memories

toyg 1y ago
> 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.
- bawolff 1y ago
  Sadly i just filed a bug to remove the xslt option from mediawiki's api. By terrible i just mean the code was really hacky. I was a newbie and exploring.

cousin_it 1y ago

Maybe off topic, but I was really inspired by this article and started thinking about other ways to have "in-browser templating". And then realized that the old function document.write() is actually very convenient for this. Tried to write up the pros and cons here: https://vladimirslepnev.me/write https://vladimirslepnev.me/write Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/write https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...