Rather than just build my own blog on it, I wrote it up for others to use and I've published it on GitHub https://github.com/vgr-land/vgr-xslt-blog-framework (2)
Since others have XSLT on the mind, now seems just as good of a time as any to share it with the world. Evidlo@ did a fine job explaining the "how" xslt works (3)
The short version on how to publish using this framework is:
1. Create a new post in HTML wrapped in the XML headers and footers the framework expects.
2. Tag the post so that its unique and the framework can find it on build
3. Add the post to the posts.xml file
And that's it. No build system to update menus, no RSS file to update (posts.xml is the rss file). As a reusable framework, there are likely bugs lurking in CSS, but otherwise I'm finding it perfectly usable for my needs.
Finally, it'd be a shame if XSLT is removed from the HTML spec (4), I've found it quite eloquent in its simplicity.
(1) https://news.ycombinator.com/item?id=44393817
(2) https://github.com/vgr-land/vgr-xslt-blog-framework
(3) https://news.ycombinator.com/item?id=44988271
(4) https://news.ycombinator.com/item?id=44952185
(Aside - First time caller long time listener to hn, thanks!)
To do this dynamically I serve the content as I wrote it with a single processing instruction that refers to a stylesheet. This is elegant, isn't it? It is less efficient than a static site, but not that different from a typical HTML: HTML, CSS, JS. It is also trivial to change it to build statically (or to embed all the resources and XSLT into individual XML files, although this would be strange.)
And if browsers supported alternative stylesheets it would be trivial to provide alternative renderings at the cost of one processing instruction per rendering. Why don't they? Isn't this puzzling? I think it is even in the specification.
Of course everyone is free to create things they want with their own abstractions, but let's not pretend that it's an optimal solution. Elegance and optimal are often at odds.