As another example, mine: https://chrismorgan.info/blog/tags/meta/feed.xml https://chrismorgan.info/blog/tags/meta/feed.xml. I’ve also deployed almost exactly t

As another example, mine: https://chrismorgan.info/blog/tags/meta/feed.xml https://chrismorgan.info/blog/tags/meta/feed.xml. I’ve also deployed almost exactly the same stylesheet in one or two other places, e.g. https://ganintegrity.com/blog/feed.xml https://ganintegrity.com/blog/feed.xml which also demonstrates pagination (very uncommonly encountered, and I have no idea of feed reader support, but a useful concept that allows you to keep your feed file small while still (at least nominally) containing all the historical entries). My XSL stylesheet is rather fancy in what it supports. Sometimes because I actually use that fanciness (e.g. supporting HTML in all text constructs, not just <atom:content>, because I use HTML titles), sometimes just for the sake of correctness or completeness (e.g. passing through xml:lang as a lang attribute, or more obscure elements like atom:rights), and sometimes for things that I might use some day but haven’t yet (e.g. turning audio/video enclosures into <audio>/<video> elements, for podcasts). https://chrismorgan.info/atom.xsl https://chrismorgan.info/atom.xsl is for Atom, and I’ve also written an RSS variant of it, purely for use in podcasts since podcasts are stupidly stuck with RSS (and it’s almost all Apple’s fault and I hate it): https://temp.chrismorgan.info/2022-05-10-rss.xsl https://temp.chrismorgan.info/2022-05-10-rss.xsl. Developing using XSLT is an interesting throwback to how web development used to be, because this stuff is basically frozen as it was twenty years ago. Almost all errors are fatal, diagnostics vary between nonexistent and poor (remember when you basically had to bisect to figure out what precisely broke things?), and the dev tools you’ve grown used to can’t help you when anything goes wrong. Also there are probably more bugs than there used to be. And documentation is bad (a lot of load-bearing functionality is completely undocumented). And browsers are much more inconsistent in their behaviour than you’ve grown used to (welcome back to the days of enforced trial and error, and having to check things in multiple browsers). (You get some of the same weirdnesses if you try shipping HTML using XML syntax, but it’s mostly XSLT-specific.) Some particular issues: • The stylesheet needs client-side JavaScript to render any type="html" content (HTML serialised as text), because Firefox doesn’t support the (admittedly optional) disable-output-escaping="yes" XSLT feature. (I’m puzzled by this lack even when using <xsl:output method="html"/>—and yes, Firefox and Chromium do both produce HTML-syntax documents in this case, not XML-syntax documents. I check this by searching for an xmlns attribute an all elements’ outerHTML, not sure if there’s a more direct check and I’d love it if someone knew one, ’cos this stuff regularly matters in JavaScript libraries—loads of libraries will break if run in an XML-syntax document due to assumptions made that no longer hold. OK, enough of this long parenthesis.) Therefore I recommend using XML syntax for the HTML instead (type="xhtml" in Atom, no equivalent in RSS because RSS is a disaster), and expect to do so for whatever next refresh I do of my own website. • The stylesheet needs client-side JavaScript to resolve URLs if you use xml:base, since browsers just don’t support that at all any more (if they ever did?). • If you make an error in the XSLT, Firefox will often point to exactly where the error is, but just as often give a completely useless generic old-school XML parse error screen. It validates declared XSLT 1.0 stylesheets, and is all round not very forgiving of errors, which is good, except that I wish the error reporting was more reliable. • Chromium is more forgiving of errors, mostly for the worse, blithely ignoring some XSLT 1.0 errors that you really wish it would point out because you have certainly done something wrong. On errors it won’t overlook, it will leave you with an document empty save for an xml-stylesheet ProcessingInstruction, not put anything in the dev tools console, and print the error to stderr (and with no stack trace in the XML or XSLT, which is painful)—I’m mildly surprised with myself that I even thought to run it in a terminal to see if there was any output there, but I guess I was getting desperate one time when everything was working fine in Firefox but not in Chromium. • In Firefox, pages that use XSLT will sometimes just hang during loading (seems to happen very often, maybe even always?, when it’s the first navigation in a new tab). Haven’t ever filed a bug about this. My wild guess is that this probably started happening at some point in the switch to a multi-process architecture. • If you reload the page in Firefox while the dev tools are open, the dev tools are now effectively dead until you close and reopen them. Bear in mind also that the dev tools operate on the post-transform document, not on the source XML. Haven’t ever filed a bug about this. If you try working on this stuff, you’ll want to keep a copy of the XSLT 1.0 and XPath 1.0 specs open. They’re the best documentation you’re likely to find, and honestly pretty good. Because each is a single document, you can search through for keywords nice and easily. I’ve been very tempted to try shipping a website where pages are Atom documents (the list, a feed document, and individual pages entry documents), mostly just for fun, but I’d want to inspect browser support more carefully before doing this, and I’d need to nail down that Firefox hang first too.