Seems rather absolutist. XSLT was an idea that sounded good, but in practice was quite awkward (like many xml technologies) and never got off the ground. Do we really need to hang every failed experiment around browser vendors' necks forever? I would prefer they work on things people care about.
From one of the issue trackers:
"While it's important to not break existing web content, it's also important to prevent security vulnerabilities. XSLT has been in maintenance mode in browsers and has been an ongoing source of security issues."
> and never got off the ground […] failed experiment
I wouldn't quite call it it a failed experiment; I've personally used it in a couple of my websites [0] and I've had pretty good experiences with it.
> it's also important to prevent security vulnerabilities
The security concerns seem disingenuous to me, since sandboxing libxslt has already been implemented and would immediately solve any security concerns [1].
> Seems rather absolutist.
I agree. As far as I can tell, this is just some developers at Google making a poor technical decision, and not some greater conspiracy against the open web.
LOL, what?? I used to work in shops, circa early 2000's, where 100% of the report-generation was driven by XSLT. I'm pretty sure it had massive corporate penetration at some point, especially when riding along with Microsoft's pervasive-at-the-time support of the standard. And I'm sure it's still got decent penetration out there.
By this standard, every desktop should still ship with a copy of Internet Explorer 6. Most of what made it "special" compared to say, the contemporary Firefox 2.0, was its huge pile of special sauce used only in corporate settings. That stuff had massive corporate penetration as well, but we moved on because ActiveX in the browser wasn't worth the security cost of keeping it around.
If there are important legacy things sitting around corporate environments that literally require XSLT to function, they've had over a year of warning in which to sort it out -- port it to something else, or, pick some alternative browser, pin its version, and set it up with a proxy that can only access your weird XSLT sites. They'll be improving their own security posture with that move, as well!
Random corporations' failure to plan doesn't constitute a need for the rest of the world to continue to maintain obsolete technologies for free.
You can install an XSLT processor plugin in a corporate setting. This is about the public web.
IMO the main use of client-side XSLT was making people say "what the-?" when they viewed source, because they'd get an XML document full of your entirely custom tags, not the output of the XSLT processor. Which is pretty cool in itself but not worth the attack surface.
You're ignoring the actual use case: people would view the XML with XSLT in browser and see a web page in a format that they could read and appreciate, and computers could read the XML ignoring the XSLT and get a dataset that they could manipulate for further purposes.
Consider an API that returns not JSON but XML: a human viewing that data in a web browser would see a web page depicting the data, while a script fetching that data would get the underlying data as an intelligible and manipulable structure for further operations. The example usually given was a CD tracklist: a human would get a readable list, while a script would get data about titles, artists, etc, and could file that in a music library or perform other operations on it. I worked with TEI: a human could read a book encoded as TEI and transformed by XSLT into a web page that reproduced the text of the book, but a CMS collecting texts into a corpus could pull bibliographic data from the XML and index the TEI file among others into a library. The main idea was that underlying data should be separated from its presentation, so that XML files would function as data models for different consumers, while XSLT transformed that data for human consumers, and automated consumers would operate on the underlying model. If you remember the late 90s and early 00s, separating data from presentation of data was a major goal, and XSLT did that.
Heh, flashbacks to Adero - a y2k-ish startup to do "the Akamai thing" but with XSLT running on our edge nodes, so you could have sophisticated personalization while the upstream site had hugely cacheable snippets. (One of our reference examples was a sports news site where you specified your interests and got a custom "newspaper" - assembled in our edge servers, not your browser.)
(I suspect if you had a catalog of "ways your startup can choose badly" for that era, we hit a lot of them. My top 3 were "attempt to do server balancing with a day's worth of latency data, using a perl script that took more than 24 hours to run and sometimes failed entirely", "Having a 20 person IT department to manage an outlook server for a 100 person company", and "Offering a senior engineer a VP position with firing authority to fix the outlook problem" :-)
We used XSLT for literally every UI, for generating C++ for certain types of classes, and for generating SQL for very large reporting systems, etc. It was used in damned near everything.
I am sure someone is working on a polyfill using wasm. This won't unbreak the rest of the web, but it will still allow for a clean separation of concerns.
I know "chrome is their browser" but Google has no business unilaterally decided what the fucking web runs now. They are just a big fucking adriddled bully.
The "we tried, it failed" story would be a lot more interesting in its bland boring shitty conservative dismissal rejection if the browsers had ever tried to support it. XSLT shipped 1.0 in 1999 and the browsers afaik never once ever did any further work, never bothered on the 2.0 (2007, incredibly better), 3.0 (2017), or new 4.0 (upcoming). Devs had to deal with the pretty jank early version, which changed a lot for 2.0! Massively! For massive betterment.
It's so so cheap and easy to discard and downput. I recommend to those desiring the path of the engineer the builder to be more sensitive. To tune in to what is good, what aspects did work. Look for value. The people in this world need those instincts, to look and assess and collect. The story of why things maybe don't work is the contrapositive failure, the same post hoc ergo propter hoc, but for the failure case. It's wrong, or at least, it usually misses the realer stories. It's a bad analysis filter.
This refusal to ever see the maybe, better, possibly rejects your ability to see and tune for more. Progress on, stop rejecting. Get good. Find good. Look for the good. Bring out the good. Or if not, consider the perhaps. If nothing else, more neutrally: let not you tie your wagon every time to the current of what is! (Another world is possible.)
Ok, well, in good humor I will engage with the ideas of xslt in the browser now.
I see the appeal of being declarative about transforming your data like this, but I don’t think it works out. Simple cases are ok, but then either (1) when things get more demanding your users hit a wall and have to rewrite in some other environment (2) you have to add a lot of complexity and typical programming language flow control constructs, which are an awkward fit, or maybe (3) you provide some kind of "unsafe" trap door to a more traditional environment. XSLT mostly went with 2, and the result is that you get a programming language that is very un-ergonomic for anything other than simplest cases. Maybe I'm overly sensitive to this because there are non-xml, non-xslt cases where I have committed to paths like this and have spent more brainpower than the problems merited on trying to do it "right", where right was kind of arbitrary. It can be an addictive brainteaser!
Second, there's just not much reason for it to be in the browser. XML served on a site is very likely to be view on the data, not the native form of the data on the backend. It's much more straightforward to have whatever transformations you need to do start from the native form of the data than to stack the transformations over xml. And if XSLT is what's convenient? Great! Do it on the back end. In 1999 that didn't seem like such an easy decision.
> there's just not much reason for it to be in the browser
Aside from the fact that it's a widely implemented, mature standard and the reason given in the article which happens to be one of the most important things in world of browsers ("Don't break the Web"), sure, there's no reason.
The title needs an “in browsers” suffix to be added. XSLT has been doing fine for transforming XML everywhere else (we have an application that still uses it in a data pipeline because the application was developed quite some time ago and the formats haven’t changed much).
I remember when in 2006 I updated my personal website to work via XML/XSLT. Opera at the time had no support for this so only Firefox users were able to use it in full. This was my only experiment with XSLT.
I've moved to HTML and never thought of the technology since. At times I was forced to use XML cause I was a .NET 2.0/3.5 junkie, but I remember how later MS switched to JSON in .NET Core and all.
Never used XML since. And Markdown has since become a gold standard for my personal documents. I'd rather work with the strict limits of MD than spend time trying to support endless variety of things in XML.
I would honestly ask your help to enlighten me on the necessity of XSLT. I'm totally willing to be wrong here. Can someone explain me how it is used?
> I would honestly ask your help to enlighten me on the necessity of XSLT. I'm totally willing to be wrong here. Can someone explain me how it is used?
It's pretty hard to beat when you need to transform some specific XML format into something else. Which isn't needed as often these days since XML is less popular than it used to be, but if you're stuck with XML, then XSLT is still a good choice.
For example, I personally use it for parsing video game save files and for displaying my Atom feed in a prettier format [0]. It's certainly possible to replace both of these with pure JavaScript, but XSLT is a really elegant solution here.
I find this whole removal idea a bit lazy.
In theory some logic possibly declares some
aspects of the BOM/DOM must be JS for introspection
reasons, etc, but the reverse can't really be true..
There's nothing that can declare things like XSLT
must be more native than a little trick with a
otherwise standard JS VM, so the unique security
edges of delegating things to a second class
backwards support level could be quite small.
I used to use FTP in Windows Explorer, Internet Explorer, and Mozilla Firefox about 15 to 30 years ago. It was convenient at the time. FTP was unceremoniously killed in mainstream browsers too. You can still use it through other software and raw libraries. Later, I read the protocol specification and realized it is badly designed - though at least simple and concise compared to the sprawling number of features in HTTP.
I have good memories of using XSLT. It was a neat idea at the time.
I suppose the world has nearly moved away from XML (for browsers, not yet for folks still enjoying SOAP APIs). And as a result, XSLT has fallen into obscurity.
Don't forget the Microsoft and the competing Open Office's twin XML formats.
Basically it's like a list of everything that was clean-sheet invented like ~ 1996-2007 used XML, then over the course of about 2 years it transitioned, and almost nothing invented after 2009 or so used it. It was like the whole software industry realized what a huge mistake and pivoted to JSON, all at once.
Yeah, all my own use of XSLT was in back-end pipelines. But I don't miss it. It suffers from the same problem as many such systems - great if what you're doing is directly supported by the tool, terrible if you need to go beyond that.
I really liked the idea of automatic XSLT translations using <?xsl-stylsheet?> tags. "View source" showing a bunch of XML instead of HTML had a great surprise factor at the time.
They are (were), and the implementation was poor anyway - the transform is not dynamic, and not even progressive. It's just a high-latency legacy static templating engine you can't upgrade.
JSON is much easier to directly access and manipulate in JS compared to XML, so I think you'd just fetch() it directly and then plug the data into something like lit-html. Which probably doesn't need bundling either since it's just template functions.
> JSON is much easier to directly access and manipulate in JS compared to XML
and yet a single newline in a text field will shatter its validity or force you to enter escaping-hell.
(I tamed that entire general problem by making https://github.com/pmarreck/printable_binary, and it will permit you to pack all binary data into a string, without any escaping issues, while retaining ascii legibility, although that requires a decoding step.)
Couldn't XSLT be rewritten not to use XML? It has all the visual appeal of a packaging accident in the hardware aisle. How would iXML implement the same functionality?
I've used Slax [0] a few times before and it's pretty nice, but it has the same problems at every other small language—little documentation and no community.
It's just an idea & very amorphous, but I dig Dorian Taylor's swet. As an idea of where we could go. wasm but also how it gets used too, what xslt could mean. https://github.com/doriantaylor/swet
Worth repeating again that the browser's never really maintained or supported XSLT at all. That, afaik, it never got past 1.0 era support. Which was bad. But there's a 2.0 (vastly better!), a 3.0, and at the same time the browsers decided not to support xslt, a 4.0.
XSLT is not a straight fit for use, doesn't seem likely to become a mainstream technology. But it's incredibly powerful & very declarative a way to produce, to transform. In that way, it's one of the most RFC 8890 The Internet Is For End Users specifications of all time, one of the only places where we can describe what is fundamentally compute as clear data, without all the opinion and decoration of code, in a clear way. We could build visualizations and explainers of what XSLT is happening, what productions are occuring, that illuminate what the page is doing, that link data in to data out in a traceable, clear, identifiable way. That the arbitrariness of code can compete with, but never so universally, only by creating it's own bespoke particular solutions, where-as XSLT has some universality.
I'm both pretty sad at the situation, but ultimately, I don't think the browser's bad choice & their laziness to help make the right thing possible matters. There's great good here, and their lack of doing the right thing doesn't actually slow things down. The problem is still that we just lack the will of the good, that developers and more so enterprises want to do the big industrial stacks, but that that is totally decoupled from what is good for the web, what is good for the users.
Seems rather absolutist. XSLT was an idea that sounded good, but in practice was quite awkward (like many xml technologies) and never got off the ground. Do we really need to hang every failed experiment around browser vendors' necks forever? I would prefer they work on things people care about.
From one of the issue trackers:
"While it's important to not break existing web content, it's also important to prevent security vulnerabilities. XSLT has been in maintenance mode in browsers and has been an ongoing source of security issues."
> and never got off the ground […] failed experiment
I wouldn't quite call it it a failed experiment; I've personally used it in a couple of my websites [0] and I've had pretty good experiences with it.
> it's also important to prevent security vulnerabilities
The security concerns seem disingenuous to me, since sandboxing libxslt has already been implemented and would immediately solve any security concerns [1].
> Seems rather absolutist.
I agree. As far as I can tell, this is just some developers at Google making a poor technical decision, and not some greater conspiracy against the open web.
[0]: https://news.ycombinator.com/item?id=45873669
[1]: https://news.ycombinator.com/item?id=45874461
> and never got off the ground
LOL, what?? I used to work in shops, circa early 2000's, where 100% of the report-generation was driven by XSLT. I'm pretty sure it had massive corporate penetration at some point, especially when riding along with Microsoft's pervasive-at-the-time support of the standard. And I'm sure it's still got decent penetration out there.
> had
> massive corporate penetration
By this standard, every desktop should still ship with a copy of Internet Explorer 6. Most of what made it "special" compared to say, the contemporary Firefox 2.0, was its huge pile of special sauce used only in corporate settings. That stuff had massive corporate penetration as well, but we moved on because ActiveX in the browser wasn't worth the security cost of keeping it around.
If there are important legacy things sitting around corporate environments that literally require XSLT to function, they've had over a year of warning in which to sort it out -- port it to something else, or, pick some alternative browser, pin its version, and set it up with a proxy that can only access your weird XSLT sites. They'll be improving their own security posture with that move, as well!
Random corporations' failure to plan doesn't constitute a need for the rest of the world to continue to maintain obsolete technologies for free.
> By this standard, every desktop should still ship with a copy of Internet Explorer 6
But the original statement being objected to was "never got off the ground", and while you can say many things about IE6, that isn't one.
You can install an XSLT processor plugin in a corporate setting. This is about the public web.
IMO the main use of client-side XSLT was making people say "what the-?" when they viewed source, because they'd get an XML document full of your entirely custom tags, not the output of the XSLT processor. Which is pretty cool in itself but not worth the attack surface.
You're ignoring the actual use case: people would view the XML with XSLT in browser and see a web page in a format that they could read and appreciate, and computers could read the XML ignoring the XSLT and get a dataset that they could manipulate for further purposes.
Consider an API that returns not JSON but XML: a human viewing that data in a web browser would see a web page depicting the data, while a script fetching that data would get the underlying data as an intelligible and manipulable structure for further operations. The example usually given was a CD tracklist: a human would get a readable list, while a script would get data about titles, artists, etc, and could file that in a music library or perform other operations on it. I worked with TEI: a human could read a book encoded as TEI and transformed by XSLT into a web page that reproduced the text of the book, but a CMS collecting texts into a corpus could pull bibliographic data from the XML and index the TEI file among others into a library. The main idea was that underlying data should be separated from its presentation, so that XML files would function as data models for different consumers, while XSLT transformed that data for human consumers, and automated consumers would operate on the underlying model. If you remember the late 90s and early 00s, separating data from presentation of data was a major goal, and XSLT did that.
Yeah but you can also implement that by appending .json to the path to get JSON, like in the old reddit API
Heh, flashbacks to Adero - a y2k-ish startup to do "the Akamai thing" but with XSLT running on our edge nodes, so you could have sophisticated personalization while the upstream site had hugely cacheable snippets. (One of our reference examples was a sports news site where you specified your interests and got a custom "newspaper" - assembled in our edge servers, not your browser.)
(I suspect if you had a catalog of "ways your startup can choose badly" for that era, we hit a lot of them. My top 3 were "attempt to do server balancing with a day's worth of latency data, using a perl script that took more than 24 hours to run and sometimes failed entirely", "Having a 20 person IT department to manage an outlook server for a 100 person company", and "Offering a senior engineer a VP position with firing authority to fix the outlook problem" :-)
We used XSLT for literally every UI, for generating C++ for certain types of classes, and for generating SQL for very large reporting systems, etc. It was used in damned near everything.
Bummer, I guess.
I am sure someone is working on a polyfill using wasm. This won't unbreak the rest of the web, but it will still allow for a clean separation of concerns.
I know "chrome is their browser" but Google has no business unilaterally decided what the fucking web runs now. They are just a big fucking adriddled bully.
Did any of that stuff happen in the browser, though?
I never learned the first thing about it, other than its name, so I'll admit ignorance.
For the UI, yes. It gave us (and our customers) a great deal of flexibility.
I can only assume we would go in a different direction, today, even if XSLT weren't "dying", but it really did fit our use case really well.
In a browser? I mean, maybe so in which case, interesting. I agree it had and has more use outside the browser.
I saw it get used a lot.
The "we tried, it failed" story would be a lot more interesting in its bland boring shitty conservative dismissal rejection if the browsers had ever tried to support it. XSLT shipped 1.0 in 1999 and the browsers afaik never once ever did any further work, never bothered on the 2.0 (2007, incredibly better), 3.0 (2017), or new 4.0 (upcoming). Devs had to deal with the pretty jank early version, which changed a lot for 2.0! Massively! For massive betterment.
It's so so cheap and easy to discard and downput. I recommend to those desiring the path of the engineer the builder to be more sensitive. To tune in to what is good, what aspects did work. Look for value. The people in this world need those instincts, to look and assess and collect. The story of why things maybe don't work is the contrapositive failure, the same post hoc ergo propter hoc, but for the failure case. It's wrong, or at least, it usually misses the realer stories. It's a bad analysis filter.
This refusal to ever see the maybe, better, possibly rejects your ability to see and tune for more. Progress on, stop rejecting. Get good. Find good. Look for the good. Bring out the good. Or if not, consider the perhaps. If nothing else, more neutrally: let not you tie your wagon every time to the current of what is! (Another world is possible.)
Ok, well, in good humor I will engage with the ideas of xslt in the browser now.
I see the appeal of being declarative about transforming your data like this, but I don’t think it works out. Simple cases are ok, but then either (1) when things get more demanding your users hit a wall and have to rewrite in some other environment (2) you have to add a lot of complexity and typical programming language flow control constructs, which are an awkward fit, or maybe (3) you provide some kind of "unsafe" trap door to a more traditional environment. XSLT mostly went with 2, and the result is that you get a programming language that is very un-ergonomic for anything other than simplest cases. Maybe I'm overly sensitive to this because there are non-xml, non-xslt cases where I have committed to paths like this and have spent more brainpower than the problems merited on trying to do it "right", where right was kind of arbitrary. It can be an addictive brainteaser!
Second, there's just not much reason for it to be in the browser. XML served on a site is very likely to be view on the data, not the native form of the data on the backend. It's much more straightforward to have whatever transformations you need to do start from the native form of the data than to stack the transformations over xml. And if XSLT is what's convenient? Great! Do it on the back end. In 1999 that didn't seem like such an easy decision.
> there's just not much reason for it to be in the browser
Aside from the fact that it's a widely implemented, mature standard and the reason given in the article which happens to be one of the most important things in world of browsers ("Don't break the Web"), sure, there's no reason.
> Do we really need to hang every failed experiment around browser vendors' necks forever?
<blink> has entered the chat </blink>
The title needs an “in browsers” suffix to be added. XSLT has been doing fine for transforming XML everywhere else (we have an application that still uses it in a data pipeline because the application was developed quite some time ago and the formats haven’t changed much).
I remember when in 2006 I updated my personal website to work via XML/XSLT. Opera at the time had no support for this so only Firefox users were able to use it in full. This was my only experiment with XSLT.
I've moved to HTML and never thought of the technology since. At times I was forced to use XML cause I was a .NET 2.0/3.5 junkie, but I remember how later MS switched to JSON in .NET Core and all.
Never used XML since. And Markdown has since become a gold standard for my personal documents. I'd rather work with the strict limits of MD than spend time trying to support endless variety of things in XML.
I would honestly ask your help to enlighten me on the necessity of XSLT. I'm totally willing to be wrong here. Can someone explain me how it is used?
> I would honestly ask your help to enlighten me on the necessity of XSLT. I'm totally willing to be wrong here. Can someone explain me how it is used?
It's pretty hard to beat when you need to transform some specific XML format into something else. Which isn't needed as often these days since XML is less popular than it used to be, but if you're stuck with XML, then XSLT is still a good choice.
For example, I personally use it for parsing video game save files and for displaying my Atom feed in a prettier format [0]. It's certainly possible to replace both of these with pure JavaScript, but XSLT is a really elegant solution here.
[0]: https://news.ycombinator.com/item?id=45873669
I find this whole removal idea a bit lazy. In theory some logic possibly declares some aspects of the BOM/DOM must be JS for introspection reasons, etc, but the reverse can't really be true.. There's nothing that can declare things like XSLT must be more native than a little trick with a otherwise standard JS VM, so the unique security edges of delegating things to a second class backwards support level could be quite small.
I used to use FTP in Windows Explorer, Internet Explorer, and Mozilla Firefox about 15 to 30 years ago. It was convenient at the time. FTP was unceremoniously killed in mainstream browsers too. You can still use it through other software and raw libraries. Later, I read the protocol specification and realized it is badly designed - though at least simple and concise compared to the sprawling number of features in HTTP.
SFTP (not to be confused with FTPS) has been the de facto replacement for FTP for the past thirty years.
I have good memories of using XSLT. It was a neat idea at the time.
I suppose the world has nearly moved away from XML (for browsers, not yet for folks still enjoying SOAP APIs). And as a result, XSLT has fallen into obscurity.
XML is still used for various formats like RSS (podcasts), SVG, sitemaps, and EPUB metadata (OPS).
XSLT is still used on the server back-end for rendering publisher documents (JATS, etc.) and for things like US bills.
I should have clarified I meant XML is no longer seriously considered for any new protocols/formats.
For XML, we can add docx/xlsx/pptx/odt/ods/odp to the list.
Don't forget the Microsoft and the competing Open Office's twin XML formats.
Basically it's like a list of everything that was clean-sheet invented like ~ 1996-2007 used XML, then over the course of about 2 years it transitioned, and almost nothing invented after 2009 or so used it. It was like the whole software industry realized what a huge mistake and pivoted to JSON, all at once.
Only the XSLT that ships with browsers.
Yeah, all my own use of XSLT was in back-end pipelines. But I don't miss it. It suffers from the same problem as many such systems - great if what you're doing is directly supported by the tool, terrible if you need to go beyond that.
I really liked the idea of automatic XSLT translations using <?xsl-stylsheet?> tags. "View source" showing a bunch of XML instead of HTML had a great surprise factor at the time.
Ah! The usual sea serpent.
Is XSLT good for transforming a [tree] data structure? H.ll yes !
Can it be adapted to transform JSON trees too? Yes, but it is a hack
Is it more declarative than coding mutations in a store? Yes.
Is it adapted to partial data chunks retrieval, aggregation and processing [also known as Web 2.0 or XmlHttpRequest or AJAX]? No.
Aren't browsers implementations of the XSLT and XPATH standards really out of date to start with?
What would be a modern equivalent of a JSON to HTML transformer?
They are (were), and the implementation was poor anyway - the transform is not dynamic, and not even progressive. It's just a high-latency legacy static templating engine you can't upgrade.
JSON is much easier to directly access and manipulate in JS compared to XML, so I think you'd just fetch() it directly and then plug the data into something like lit-html. Which probably doesn't need bundling either since it's just template functions.
> JSON is much easier to directly access and manipulate in JS compared to XML
and yet a single newline in a text field will shatter its validity or force you to enter escaping-hell.
(I tamed that entire general problem by making https://github.com/pmarreck/printable_binary, and it will permit you to pack all binary data into a string, without any escaping issues, while retaining ascii legibility, although that requires a decoding step.)
> and yet a single newline in a text field will shatter its validity or force you to enter escaping-hell.
So would a single & or > in the body of an XML element, you know.
I had an xslt file that crashed my whole server. Was just supposed to render html for a page but things got recursive.
Couldn't XSLT be rewritten not to use XML? It has all the visual appeal of a packaging accident in the hardware aisle. How would iXML implement the same functionality?
I've used Slax [0] a few times before and it's pretty nice, but it has the same problems at every other small language—little documentation and no community.
[0]: https://news.ycombinator.com/item?id=48333823
Rewriting it in JavaScript would probably give you React - not joking.
XSLT is more like a templating engine, so none of the reactivity of React. Probably more like Handlebars or Pug.
Good LWN coverage from a bit ago, https://lwn.net/Articles/1034560/
It's just an idea & very amorphous, but I dig Dorian Taylor's swet. As an idea of where we could go. wasm but also how it gets used too, what xslt could mean. https://github.com/doriantaylor/swet
Worth repeating again that the browser's never really maintained or supported XSLT at all. That, afaik, it never got past 1.0 era support. Which was bad. But there's a 2.0 (vastly better!), a 3.0, and at the same time the browsers decided not to support xslt, a 4.0.
XSLT is not a straight fit for use, doesn't seem likely to become a mainstream technology. But it's incredibly powerful & very declarative a way to produce, to transform. In that way, it's one of the most RFC 8890 The Internet Is For End Users specifications of all time, one of the only places where we can describe what is fundamentally compute as clear data, without all the opinion and decoration of code, in a clear way. We could build visualizations and explainers of what XSLT is happening, what productions are occuring, that illuminate what the page is doing, that link data in to data out in a traceable, clear, identifiable way. That the arbitrariness of code can compete with, but never so universally, only by creating it's own bespoke particular solutions, where-as XSLT has some universality.
I'm both pretty sad at the situation, but ultimately, I don't think the browser's bad choice & their laziness to help make the right thing possible matters. There's great good here, and their lack of doing the right thing doesn't actually slow things down. The problem is still that we just lack the will of the good, that developers and more so enterprises want to do the big industrial stacks, but that that is totally decoupled from what is good for the web, what is good for the users.
Related:
Chrome and Edge are removing XSLT: what breaks and what does not
https://news.ycombinator.com/item?id=50134617
I'm not going to the funeral.