Comment by fergie
11 hours ago
What is this "XSLT works natively in the browser" sourcery? The last time I used XSLT was like 20 years ago- but I used it A LOT, FOR YEARS. In those days you needed a massive wobbly tower of enterprise Java to make it work which sort of detracted from the elegance of XSLT itself. But if XSLT actually works in the browser- has the holy grail of host-anywhere static templating actually been sitting under our noses this whole time?
Browsers support XSLT v1.0 only, and from what I understand, there has been talk of depricating it.
I would rather that they introduced support for v3, as that would make it easier to serving static webpages with native support for templating.
I'm also more concerned about depreciation risk. However, you can still do a lot with XSLT 1.0. There is also SaxonJS, which allows you to run XSLT 3.0. However, embedding JavaScript to use XSLT defeats the purpose of this exercise.
It doesn't really defeat the purpose. It just shows how much fuss about avoiding JS is a sign of insisting on ideological purity rather than accomplishing any particular goal.
What exactly is the difference between generating HTML using the browser's XLST 1.0 runtime and SaxonJS's XLST 3.0 runtime? Before you say the goal is to not have to deal with JS, then you've already accomplished that goal. You don't need to touch NPM, webpack, React, JSX, etc.
Blocking first party JS is lunacy by the way.
1 reply →
Chrome has libxslt; FireFox has something called "Transformiix". Both 1.0. Chrome has no extensions, only 'exsl:node-set'; FireFox has quite a few, although not all of EXSLT.
Plug: here is a small project to get the basic information about the XSLT processor and available extensions. To use with a browser find the 'out/detect.xslt' file there and drag it into the browser. Works with Chrome and Firefox; didn't work with Safari, but I only have an old Windows version of it.
https://github.com/MikhailEdoshin/xslt-detect-ext/
I worked with a site using XSLT in the browser in 2008, but I think support goes back to the early 2000s.
I was _really_ deep into XSLT- I even wrote the XSLT 2 parser for Wikipedia in like 2009, so I'm not sure why I haven't been aware of browser native support for transformations until now. Or maybe I was and I just forgot.
It was a feature of IE5.
I updated an XSLT system to work with then latest Firefox a couple of years ago. We have scripts in a different directory to the documents being transformed which requires a security setting to be changed in Firefox to make it work, I don't know if an equivalent thing is needed for Chrome.
> massive wobbly tower of enterprise Java to make it work
It wasn't that bad. We used tomcat and some apache libraries for this. Worked fine.
Our CMS was spitting out XML files with embedded HTML that were very cachable. We handled personalization and rendering to HTML (and js) server side with a caching proxy. The XSL transformation ran after the cache and was fast enough to keep up with a lot of traffic. Basically the point of the XML here was to put all the ready HTML in blobs and all the stuff that needed personalization as XML tags. So the final transform was pretty fast. The XSL transformer was heavily optimized and the trick was to stream its output straight to the response output stream and not do in memory buffering of the full content. That's still a good trick BTW. that most frameworks do wrong out of the box because in memory buffering is easier for the user. It can make a big difference for large responses.
These days, you can run whatever you want in a browser via wasm of course. But back then javascript was a mess and designers delivered photoshop files, at best. Which you then had to cut up into frames and tables and what not. I remember Google Maps and Gmail had just come out and we were doing a pretty javascript heavy UI for our CMS and having to support both Netscape and Internet Explorer, which both had very different ideas about how to do stuff.
XSLT works, though if I'm not mistaken browsers are all stuck on older versions of the spec. Firefox has a particularly annoying bug that I run into related to `disable-output-escaping` not really working when you need to encode HTML from the document to render as actual DOM (it renders the raw HTML text).
> massive wobbly tower of enterprise Java to make it work
??
I was transforming XML with, like, three lines of VBScript in classic ASP.
The MSXML parser was pretty darn solid.
> In those days you needed a massive wobbly tower of enterprise Java to make it work
You needed the jvm and saxon and that was about it...
How deep was your file tree? Be honest! ;)
it works, i think the most visible ones are where people style their atom / rss feeds instead of rendering separate xml / html pages https://rknight.me/blog/styling-rss-and-atom-feeds/