5 ms·

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I wi

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

crazygringo 1y ago
Yeah, the idea that it's some kind of foundation of the "open web" is quite silly. I've used XSLT plenty for transforming XML data for enterprises but that's all backend stuff. Until this whole kerfuffle I never knew there was support for it in the browser in the first place. Nor, it seems, did most people. If there's some enterprise software that uses it to transform some XML that an API produces into something else client-side, relying on a polyfill seems perfectly reasonable. Or just move that data transformation to the back-end.
jerf 1y ago
What a horrible technology to wrap around your neck for rebellion's sake. XSLT didn't succeed because it's fundamentally terrible and was a bad idea from the very beginning. But I suppose forcing one's self to use XSLT just to spite Google would constitute its own punishment.
- veeti 1y ago
  It has nothing to do with the specifics of the technology. As a consumer of online content, I don't care one bit if it is styled with XSLT or CSS (though as a developer my condolences are with the author, if they worked with XSLT). However, what I do care about is that it _remains viewable and usable_. Imagine if Microsoft Word one day decided you couldn't open .doc or .rtf files from the early 2000's? The browser vendors have decided that the web is now an application delivery platform where developers must polyfill backwards compatibility, past documents be damned. And just as the article drives the point home, it doesn't have to be this way. They could just provide the polyfill within the browser, negating any purported security issues with ancient XML libraries.
zekica 1y ago
I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable. It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.
- fuzzzerd 1y ago
  I have done same thing with sitemap.xml.
- rwmj 1y ago
  I would just do this on the server side. You can even do it statically when generating the XML. In fact until all the stuff about XSLT in browsers appeared recently, I didn't even know that browsers could do it.
  - wizzwizz4 1y ago
    Converting the contents of an Atom feed into (X)HTML means it's no longer a valid Atom feed. The same is true for many other document formats, such as flattened ODF.
    - rerdavies 1y ago
      Is an XLST page a valid atom feed? Is it really so terrible to have to two different pages -- one for the human readable version, and one for the XML version?
      - wizzwizz4 1y ago
        Yes, an <?xml-stylesheet href="..."?> directive is valid in every XML document. You can use CSS to get many of the benefits of XSLT here, but it doesn't let you map RSS @link attributes to HTML a/@href attributes, and CSS isn't designed for interactivity. That's a rather significant gap in functionality. It is rather terrible to have two different pages, because that requires either server or toolchain support, and complicates testing. The XSLT approach was tried, tested, and KISS – provided you didn't have any insecure/secure context mismatches, or CORS issues, which would stop the XSL stylesheet from loading. (But that's less likely to spontaneously go wrong than an update to a PHP extension breaking your script.)
roywashere 1y ago
All browsers ever implemented was XSLT 1.0, from 1999. There were 2.0 and 3.0 for which there is an open source Java based implementation (Saxon) but this never made it into libxslt and/or browsers!
James_K 1y ago
I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.
- matthews3 1y ago
  Could you run XSLT as part of your build process, and serve the generated HTML?
  - James_K 1y ago
    No because then it would not be an Atom feed. Atom is a syndication format, the successor to RSS. I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked. This is why so many people find this objectionable. If you want to have a basic blog, you need some HTML docments and and RSS/Atom feed. The technologies required to do this are HTML for the documents and XSLT to format the feed. Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website.
    - ErroneousBosh 1y ago
      > Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website. How so? You're just generating static pages. Generate ones that work.
      - James_K 1y ago
        You cannot generate a valid RRS/Atom document which also renders as HTML.
        shadowgovt 1y ago
        So put them on separate pages because they are separate protocols (HTML for the browser and XML for a feed reader), with a link on the HTML page to be copied and pasted into a feed reader. It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.
ndiddy 1y ago
My guess is that a lot of the controversy is simply because this is one of the first times that a major web feature has been removed from the web standards. For the past 20+ years, people have grown to expect that any page they make will remain viewable indefinitely. It doesn't matter that most people don't like XSLT, or that barely any sites use it. Removing XSLT does break some websites and that violates their expectation, so they get mad at it reflexively. As someone who's interested in sustainable open source development, I also find the circumstances around the deprecation to be interesting and worth talking about. The XSLT implementation used by all the browsers is a 25 year old C library whose maintainer recently resigned due to having to constantly deal with security bugs reported by large companies who don't provide any financial contribution or meaningful assistance to the project. It seems like the browser vendors were fine with the status quo of having XSLT support as long as they didn't have to contribute any resources to it. As soon as that free maintenance went away and they were faced with either paying someone to continue maintenance or writing a new XSLT library in a safer language, they weren't willing to pay the market value for what it would cost to do this and decided to drop the feature instead.
- rerdavies 1y ago
  Sounds like EVERYBODY agrees that there isn't sufficient market value then. Even the original maintainer. And the that is indeed why the feature is being dropped: insufficient market value. Happy happy happy!
  - Capricorn2481 1y ago
    I don't think a maintainer refusing to answer spam issues from billion dollar corporations that contributes nothing back is evidence of no value to the maintainer. Unless you think FFmpeg has no market value, who has taken the same stance.
Fileformat 1y ago
Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that. I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user? https://www.rss.style/ https://www.rss.style/
- shadowgovt 1y ago
  RSS and Atom feeds are at this point a solution looking for a problem. I use RSS all the time... To keep up-to-date on podcasts. But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook.
  - basscomm 1y ago
    > But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook. I guess if you don't use social media or facebook you're out of luck?
    - shadowgovt 1y ago
      I don't see why. You can always subscribe to a newspaper. Or just use RSS and a subscription tool since it didn't just go away. What I'm saying, though, is if you don't use social media at this point you're already an outlier (I am, it should be noted, using the term broadly: you are using social media. Right now. Hacker News is in the same category as Facebook, Twitter, Mastodon, et. al. in this context: it's a place you go to get information instead of using a collection of RSS feeds, and I think the reason people do this instead of that may be instructive as to the ultimate fate of RSS for that use-case).
      - basscomm 1y ago
6510 1y ago
If you have a lot of xml data and need an UI that does complex operations that scream xpath it would be rather spectacular if it could be done without much of a back end, in the browser without js. I'm not good enough with XSLT to know if it is worth creating the problem that fits the solution.
danwilsonthomas 1y ago
Imagine you have users that want to view an XML document as a report of some kind. You can easily do this right now by having them upload a document and attaching a stylesheet to it. I do this to let people view after-game reports for a video game (Nebulous: Fleet Command). They come in as XML and I transform them to HTML. Now I do this all client-side using the browser support for XSLT and about 10 lines of javascript because I don't want to pay for and run a server for file uploads. But if I did the XSLT support in the browser would make it truly trivial to do. Now this obviously isn't critical infrastructure, but it sucks getting stepped on and I'm getting stepped on by the removal of XSLT.
basscomm 1y ago
> I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. I used it to develop a website because I'm not a programmer, but I still want to have some basic templates on my webpage without having to set up a dev environment or a static site generator. XML and XSLT extend HTML _just enough_ to let me do some fun things without me having to become a full-on programmer.

crazygringo 1y ago

Yeah, the idea that it's some kind of foundation of the "open web" is quite silly. I've used XSLT plenty for transforming XML data for enterprises but that's all backend stuff. Until this whole kerfuffle I never knew there was support for it in the browser in the first place. Nor, it seems, did most people. If there's some enterprise software that uses it to transform some XML that an API produces into something else client-side, relying on a polyfill seems perfectly reasonable. Or just move that data transformation to the back-end.

jerf 1y ago

What a horrible technology to wrap around your neck for rebellion's sake. XSLT didn't succeed because it's fundamentally terrible and was a bad idea from the very beginning. But I suppose forcing one's self to use XSLT just to spite Google would constitute its own punishment.

veeti 1y ago
It has nothing to do with the specifics of the technology. As a consumer of online content, I don't care one bit if it is styled with XSLT or CSS (though as a developer my condolences are with the author, if they worked with XSLT). However, what I do care about is that it _remains viewable and usable_. Imagine if Microsoft Word one day decided you couldn't open .doc or .rtf files from the early 2000's? The browser vendors have decided that the web is now an application delivery platform where developers must polyfill backwards compatibility, past documents be damned. And just as the article drives the point home, it doesn't have to be this way. They could just provide the polyfill within the browser, negating any purported security issues with ancient XML libraries.

zekica 1y ago

I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable. It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.

fuzzzerd 1y ago
I have done same thing with sitemap.xml.
rwmj 1y ago
I would just do this on the server side. You can even do it statically when generating the XML. In fact until all the stuff about XSLT in browsers appeared recently, I didn't even know that browsers could do it.
- wizzwizz4 1y ago
  Converting the contents of an Atom feed into (X)HTML means it's no longer a valid Atom feed. The same is true for many other document formats, such as flattened ODF.
  - rerdavies 1y ago
    Is an XLST page a valid atom feed? Is it really so terrible to have to two different pages -- one for the human readable version, and one for the XML version?
    - wizzwizz4 1y ago
      Yes, an <?xml-stylesheet href="..."?> directive is valid in every XML document. You can use CSS to get many of the benefits of XSLT here, but it doesn't let you map RSS @link attributes to HTML a/@href attributes, and CSS isn't designed for interactivity. That's a rather significant gap in functionality. It is rather terrible to have two different pages, because that requires either server or toolchain support, and complicates testing. The XSLT approach was tried, tested, and KISS – provided you didn't have any insecure/secure context mismatches, or CORS issues, which would stop the XSL stylesheet from loading. (But that's less likely to spontaneously go wrong than an update to a PHP extension breaking your script.)

roywashere 1y ago

All browsers ever implemented was XSLT 1.0, from 1999. There were 2.0 and 3.0 for which there is an open source Java based implementation (Saxon) but this never made it into libxslt and/or browsers!

James_K 1y ago

I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.

matthews3 1y ago
Could you run XSLT as part of your build process, and serve the generated HTML?
- James_K 1y ago
  No because then it would not be an Atom feed. Atom is a syndication format, the successor to RSS. I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked. This is why so many people find this objectionable. If you want to have a basic blog, you need some HTML docments and and RSS/Atom feed. The technologies required to do this are HTML for the documents and XSLT to format the feed. Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website.
  - ErroneousBosh 1y ago
    > Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website. How so? You're just generating static pages. Generate ones that work.
    - James_K 1y ago
      You cannot generate a valid RRS/Atom document which also renders as HTML.
      - shadowgovt 1y ago
        So put them on separate pages because they are separate protocols (HTML for the browser and XML for a feed reader), with a link on the HTML page to be copied and pasted into a feed reader. It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.

ndiddy 1y ago

My guess is that a lot of the controversy is simply because this is one of the first times that a major web feature has been removed from the web standards. For the past 20+ years, people have grown to expect that any page they make will remain viewable indefinitely. It doesn't matter that most people don't like XSLT, or that barely any sites use it. Removing XSLT does break some websites and that violates their expectation, so they get mad at it reflexively. As someone who's interested in sustainable open source development, I also find the circumstances around the deprecation to be interesting and worth talking about. The XSLT implementation used by all the browsers is a 25 year old C library whose maintainer recently resigned due to having to constantly deal with security bugs reported by large companies who don't provide any financial contribution or meaningful assistance to the project. It seems like the browser vendors were fine with the status quo of having XSLT support as long as they didn't have to contribute any resources to it. As soon as that free maintenance went away and they were faced with either paying someone to continue maintenance or writing a new XSLT library in a safer language, they weren't willing to pay the market value for what it would cost to do this and decided to drop the feature instead.

rerdavies 1y ago
Sounds like EVERYBODY agrees that there isn't sufficient market value then. Even the original maintainer. And the that is indeed why the feature is being dropped: insufficient market value. Happy happy happy!
- Capricorn2481 1y ago
  I don't think a maintainer refusing to answer spam issues from billion dollar corporations that contributes nothing back is evidence of no value to the maintainer. Unless you think FFmpeg has no market value, who has taken the same stance.

Fileformat 1y ago

Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that. I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user? https://www.rss.style/ https://www.rss.style/

shadowgovt 1y ago
RSS and Atom feeds are at this point a solution looking for a problem. I use RSS all the time... To keep up-to-date on podcasts. But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook.
- basscomm 1y ago
  > But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook. I guess if you don't use social media or facebook you're out of luck?
  - shadowgovt 1y ago
    I don't see why. You can always subscribe to a newspaper. Or just use RSS and a subscription tool since it didn't just go away. What I'm saying, though, is if you don't use social media at this point you're already an outlier (I am, it should be noted, using the term broadly: you are using social media. Right now. Hacker News is in the same category as Facebook, Twitter, Mastodon, et. al. in this context: it's a place you go to get information instead of using a collection of RSS feeds, and I think the reason people do this instead of that may be instructive as to the ultimate fate of RSS for that use-case).
    - basscomm 1y ago

6510 1y ago

If you have a lot of xml data and need an UI that does complex operations that scream xpath it would be rather spectacular if it could be done without much of a back end, in the browser without js. I'm not good enough with XSLT to know if it is worth creating the problem that fits the solution.

danwilsonthomas 1y ago

Imagine you have users that want to view an XML document as a report of some kind. You can easily do this right now by having them upload a document and attaching a stylesheet to it. I do this to let people view after-game reports for a video game (Nebulous: Fleet Command). They come in as XML and I transform them to HTML. Now I do this all client-side using the browser support for XSLT and about 10 lines of javascript because I don't want to pay for and run a server for file uploads. But if I did the XSLT support in the browser would make it truly trivial to do. Now this obviously isn't critical infrastructure, but it sucks getting stepped on and I'm getting stepped on by the removal of XSLT.

basscomm 1y ago

> I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. I used it to develop a website because I'm not a programmer, but I still want to have some basic templates on my webpage without having to set up a dev environment or a static site generator. XML and XSLT extend HTML _just enough_ to let me do some fun things without me having to become a full-on programmer.