Death Comes for XSLT

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/

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.

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.

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?

I'm not going to the funeral.

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?

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.