Death Comes for XSLT

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.

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

I find XSLT removal a rather bad argument for "browser vendors bad". Browser vendors do of course make bad decisions that impact people to serve their own purposes, but in this case the "people" in question are just bloggers who want their RSS feed to render pretty on the browser, which isn't all that consequential and makes the whole discussion look like frivolous outrage. There are probably way better examples to lead with.

Edit: You don't need XSLT to style your feeds. I've been using a script that does the same [1], because browsers will read and run XHTML <script> tags inside any XML document.

[1]: https://dayli.ly/misc/render-feed/

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 had an xslt file that crashed my whole server. Was just supposed to render html for a page but things got recursive.

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

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.

Only the XSLT that ships with browsers.

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?

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'm not going to the funeral.

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.