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."
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.
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.
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 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.
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."
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.
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.
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 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.
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.