My blog is also its own RSS feed

Created: — modified: — tags: meta

On the main page of this blog (which lists all posts), right-click an empty place and select "View Page Source (Ctrl+U)". What do you see? An RSS feed! (or, rather, it's technically an Atom feed, but who actually cares) But how? And... Why?!..

Apparently, it's possible to style RSS feed to look nicer than a raw XML when opened in a browser. To do so, you need to use a thing called XSLT - eXtensible Stylesheet Language Transformation. Basically, it's an XML document which explains how to transform one document (usually XML) into another one - for example, HTML.

W3schools has a simple example of transforming an XML (in that example, some CD disc database) to an HTML. Another simple example is this XSLT stylesheet for RSS 2.0 from author of aboutfeeds.com, which I saw used on more than one website.

But wait a second: RSS feed is a list of posts, with short summaries and links to original pages, but main page of my blog is also a list of posts with short summaries and links to original pages... So can't beautified RSS feed serve as main page of my blog, too?

NOTE that here I use term "RSS" in two ways:

Probably that's because I remember when RSS first appeared in my browser, and since then the term got genericized in my mind and started meaning not the specific technology but a general idea.

And after looking through some of more complex examples and Hacker News comments, I decided to go with Atom feed format instead of RSS 2.0, primarily for two reasons:

and also because of the above comment mentioning that Atom is better specified and has a place to put (X)HTML into it, while RSS 2.0 is relying on feed reader's interpretation. So I loaded up Atom spec in one tab, Mozilla's XSLT reference in another, and started hacking.

I thought it will take me two hours. But it actually took me not two, but three. And not hours, but days!1 😅

Also worth noting that XSLT has some features that make some Javascript parts of lazyblog redundant. Like, you probably would expect XSLT to have <xsl:for-each> tag to walk through all child elements of some element. But it also has <xsl:sort> tag (w3schools has a nice example for it), which makes Javascript-powered sorting redundant. Together with <xsl:if> and <xsl:choose>, and with a bunch of functions for string manupulation, this can replace filtering and maybe even search... If only browsers had a feature to pass query parameters to XSLT templates! Then I could probably use XSLT for everything and stop using javascript entirely. But oh well, looks like browser support for XSLT is indeed limited to being "static" and simply processing server responses, while dynamic parts require Javascript or server-side scripting... But where's fun in that?

And here's the result - visually it's totally indistinguishable from the previous version2! Apart from the "Last update" timestamp in top-right corner... That's because Atom feed spec requires feed to include an "updated" timestamp (presumably for readers to stop processsing a feed if it didn't change), so I had to add the feature of updating the last built timestamp to lazyblog... But then, why not show it in HTML, too? It adds a bit of anxiety, though: now I know that I can't do some change quietly, hoping that none will notice it - this timestamp will tell everyone that something changed there recently... And for those who check my blog regularly (let's pretend there are people like this): they will also see it as "something changed since your last visit", but might not see what exactly, and left wondering what they missed... The only people who might benefit from it are those who use actual RSS feed reader programs, because these programs might highlight the modified entries to them.

The only thing that I don't like is that in previous version, index template page was a 70-lines file, almost completely "plain HTML", with just some $template_placeholders, while in new version this HTML is smeared among 300 lines of XML... But oh well, what can we do? XSLT also supports document() function to load and parse an external document, which I already use to support different languages, so maybe I could use that to load one more file -an XHTML template, and then XSLT "program" will simply fill placeholders inside it?.. Too bad there are no built-in template manipulation functions in XSLT. Even Linux command line has it! Although since 2003, according to Copyright note in the above page, while XSLT 1.0 (the latest version supported by web browsers), according to this page, was finalized in 1999, so someone might argue that XSLT predates envvsubst, and my argument is wrong, but come on! XSLT is itself a templating language!

Would I recommend anyone to do the same? Not sure :-) I would advice you to read through this comment first (note the comment is from 2023, and author of that comment also created a XSL stylesheet which I linked before - it is both bigger and more advanced than mine, so his opinion on this subject should be worth listening even more than mine), and then I can confirm that in 2024 I've seen it all, too: Firefox tab freezing if Dev Tools are open, Chrome being more "picky" (or, rather, strict) about XSLT errors and printing them to terminal3, but also Chrome inserting two <br> elements when asked for one and having serious performance issues once, until restarted4.

And yes, debugging indeed feels like back in early 2000s: printf debugging, whole page being blank in case of a single mistake somewhere... So quite often I ended up deleting chunks of XSLT stylesheet using binary search to find where the error was.

Also, turns out, I'm not the first one to have RSS feed as the main page!

  1. and then more than a whole day to write this blog post ↩

  2. previous version preserved here just for reference, won't be updated in a future. ↩

  3. Actually, because of this, I found it easier to test using Chrome during development, because "what works in Chrome will likely work in Firefox, too" (but not always the other way around), but also because unlike Firefox, Chrome printed these errors at least somewhere! Although I must admit I didn't try starting Firefox from terminal. ↩

  4. Chrome performance issues might be related to the fact that just before that I changed screen scaling back from 125% to 100% in display settings, while running under Wayland. Firefox picked up the change instantly, while Chrome was still at 125% scale until restart, so something is definitely different between them. ↩