3 ms·

Oh what filun it was when Internet Explorer supported XSLT natively ... have your webpage content in an RSS file or similar, add XSLT Stylesheet reference and t

Oh what filun it was when Internet Explorer supported XSLT natively ... have your webpage content in an RSS file or similar, add XSLT Stylesheet reference and the browser would render it as nice web page. Nice way to have a single page blog without server side code, no generator step or anything. But well, Firefox didn't do it that way, thus no proper use.

palsecam 1y ago
Oh but yes, Firefox (and Chrome) do support XSLT natively! See https://paul.fragara.com/feed.xml 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/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(); Server-side, I’ve leveraged XSLT (2.0) in the build process of another website, to slightly transform (X)HTML pages before publishing (canonicalize URLs, embed JS & CSS directly in the page, etc.): https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.xsl https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.x...
- johannes1234321 1y ago
  Interesting, it's more than 20 years since I tried anything in that space. Thanks for the correction.
naniwaduni 1y ago
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.
zeendo 1y ago
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.
acdha 1y ago
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.
- johannes1234321 1y ago
  Not sure the experience on failures of PHP scripts of that time was any better :)
  - acdha 1y ago
    Every alternative was massively better for two key reasons: the first is that it happened on the server where you knew about it and could control what happened[1], and because you only had one kind of server to monitor whereas client side errors had to be tested in a wide range of client OS and browser combinations, much larger than today where automatic updates are just taken for granted. There was a third way in which PHP was often better: continuing after errors has drawbacks from a security and correctness perspective but as a user it was often the case that you could read what you wanted on a partially functioning page. I think we’ve largely matured out of the point where that’s good, but people often did benefit at the time. 1. remember, this was before things like Sentry happened for front end error collection, and XML-related issues still can’t be handled by JavaScript even now.
wowczarek 1y ago
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.
acabal 1y ago
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 https://standardebooks.org/feeds/opds/new-releases (use view source to see that it's an XML document).

palsecam 1y ago

Oh but yes, Firefox (and Chrome) do support XSLT natively! See https://paul.fragara.com/feed.xml 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/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(); Server-side, I’ve leveraged XSLT (2.0) in the build process of another website, to slightly transform (X)HTML pages before publishing (canonicalize URLs, embed JS & CSS directly in the page, etc.): https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.xsl https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.x...

johannes1234321 1y ago
Interesting, it's more than 20 years since I tried anything in that space. Thanks for the correction.

naniwaduni 1y ago

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.

zeendo 1y ago

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.

acdha 1y ago

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.

johannes1234321 1y ago
Not sure the experience on failures of PHP scripts of that time was any better :)
- acdha 1y ago
  Every alternative was massively better for two key reasons: the first is that it happened on the server where you knew about it and could control what happened[1], and because you only had one kind of server to monitor whereas client side errors had to be tested in a wide range of client OS and browser combinations, much larger than today where automatic updates are just taken for granted. There was a third way in which PHP was often better: continuing after errors has drawbacks from a security and correctness perspective but as a user it was often the case that you could read what you wanted on a partially functioning page. I think we’ve largely matured out of the point where that’s good, but people often did benefit at the time. 1. remember, this was before things like Sentry happened for front end error collection, and XML-related issues still can’t be handled by JavaScript even now.

wowczarek 1y ago

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.

acabal 1y ago

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 https://standardebooks.org/feeds/opds/new-releases (use view source to see that it's an XML document).