XSLT: A Precision Tool for the Future of Structured Transformation

Oh but yes, Firefox (and Chrome) do support XSLT natively! See https://paul.fragara.com/feed.xml as an example (the Atom feed of my website, styled with XSLT).

FTR, there’s also XSLTProcessor (https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcess...) available from Javascript in the browser. I use that on my homepage, to fetch and transform-to-HTML said Atom feed, then embed it:

  const atom = new XMLHttpRequest, xslt = new XMLHttpRequest;
  atom.open("GET", "feed.xml"); xslt.open("GET", "atom2html.xsl");
  atom.onload = xslt.onload = function() {
    if (atom.readyState !== 4 || xslt.readyState !== 4) return;
    const proc = new XSLTProcessor;
    proc.importStylesheet(xslt.responseXML);
    const frag = proc.transformToFragment(atom.responseXML, document);
    document.getElementById("feed").appendChild(frag.querySelector("[role='feed']"));
  };
  atom.send(); xslt.send();

Firefox does support XSLT. At Standard Ebooks, our ebook OPDS/RSS feeds are styled with XSLT when viewed with a browser. See for example https://standardebooks.org/feeds/opds/new-releases (use view source to see that it's an XML document).

To this day, XSLT is one of basically two ways to deliver "content" and "layout" almost fully separately and have a browser combine that in a presentable way, entirely on the client—the other, of course, being to make a mess in JS.

I used XSLT and Active Server Pages to build my school district's website back around 2000 - each school had their own page and each teacher had their own, too - teachers could modify their pages directly in the browser.

I forget the _exact_ mechanics but it was definitely all done in Internet Explorer with XML as the actual content per-page and transformation was done using XSLT.

Interesting but I definitely hate XSLT as a result. Considering this was my first real programming job, it's surprising I continued.

The bigger problem was the poor experience when anything failed and your users got an inscrutable error page or, if it was a gap in functionality rather than a hard compatibility error, parts of the page didn’t work as expected and you might not even notice if depended on a browser / MS shared library version you didn’t use.

Philosophically I like the idea but that era needed a lot more attention to tool quality and interoperability. I’m not sure anything anyone on an XML-based standards committee did after the turn of the century mattered as much as it would have if the money had been spent improving tools and avoiding things like so many tools relying on libxml2 / libxslt and thus never getting support for newer versions of XPath, XSLT, etc.

I did this in embedded some 20+ years ago, I was working on a project where the microcontroller didn't have enough resources to do much CGI and store much more than a few kilobytes, so a big dashboard with tens of temperature gauges and other things was all done as a combination of serving XML data and a single, small XSLT file and the rest was all in the browser. Fun times indeed.

Even worse, in practice you still often only get to use XSLT 1 and XPath 1, because that's what the common Open Source libraries (i.e. libxml/libxslt and Xalan) typically used to embed XSLT into Software support. (The existence of EXSLT should better be forgotten). For anything else, esp. dedicated standalone XSLT development, there is basically only saxon. I wish, there was better Open Source support for XSLT/XPath 2+ but i don't think it's likely to happen.

There's a working group dedicated to breathing new life into the standard:

https://qt4cg.org/specifications/xslt-40/Overview.html

Last updated just under a week ago!

I'd say damn near 20yrs. I used it quite extensively about 10yrs ago and it was an odd one then, but was very useful for the purpose we had (semantic validation of XML payloads).

XSLT is a bad programming language wrapped around XPath. I'd rather take any existing general purpose programming language, add an XPath library to it, and write anything I'd do in XSLT in a programming language where I don't have to wait until version 3.0 for, well, all this stuff: https://www.w3.org/TR/xslt-30/#whats-new-in-xslt3

And a lot of that "badness" is precisely that XSLT is a very closed, scarcity-minded language where basic library and language features have to be routed through a standards committee (you think it's hard to get a new function into Python's or Go's standard library?), when all you really need is an XPath library and any abundance-mindset language you can pick up, where if you need something like "regular expression" support you can just go get a library. Or literally anything else you may need to process an XML document, which is possibly anything. Which is why a general-purpose language is a good fit.

That "What's New In XSLT 3.0" is lunatic nonsense if you view it through the lens of being a programming language. What programming language gets associative arrays after 18 years? And another 8 years after that you still can't really count on that being available?

Programming languages tend to have either success feed success, or failure feed failure. Once one of those cascades start it's very difficult to escape from them. XSLT is pretty firmly in the latter camp, probably kept alive only by the fact it's a standard and that still matters to some people. It's frozen because effectively nobody cares, because it's frozen, because nobody cares.

I definitely recommend putting XPath in your toolbelt if you have to deal with XML at all though.

It's a problem in both the XML and RDF [1] worlds that the same representation gets used for everything. Part of the success of CSS is that it looks different from HTML, it could have been expressed with angle brackets and I think people would have had terrible trouble understanding where the HTML ends and the CSS begins.

[1] Oddly, SPARQL-in-Turtle isn't half bad to my eye, see https://spinrdf.org/sp.html

Cocoon was cool but damn that thing was slow. At the end you had to do a lot of caching to end up with something usable.

XSLT up to 1.1 is a totally different language, actually.

It was actually a hypertext format as opposed to JSON. So HATEOS actually made sense. The fact that we went backwards in terms of no longer using a hyptertext format for almost all web requests is one of the dumbest moves in web development. I get the incentives that influenced it, but yuck.