I’m moving from Atom to RSS 2.0 feeds.

Intriuged by the 'Comments' links I kept seeing on some entries in my feed reader, I added one for my articles. In the process, I moved to RSS 2.0 feeds. Here's why and my thoughts on the move.

Both CSS-Tricks.com and FourKitchens.com use WordPress under the hood.

They are a great example of how the decision to use an established framework lends itself to good practices — without the requirement of an extensive amount of effort or knowledge from its users.

Case in point, take the following two entries from my Miniflux feed reader (which I self host):

An entry on Miniflux by Four Kitchens showing its title, author, time published, time required to read in minutes, and finally, actions a user can take such as: read, star, original, comments.
An entry on Miniflux by CSS Tricks showing its title, author, time published, time required to read in minutes, and finally, actions a user can take such as: read, star, original, comments.

You will notice it has a ‘Comments’ link. Let me make a bold claim: pretty much 9 out of 10 of my feeds don’t carry this, even when they offer comments.

To figure out how I could add this for my articles too, I looked at Four Kitchen’s RSS feed and found a comments tag with a value that would link to the comments section on the page.

Quite simple, I thought.

Here’s what I did next:

  1. Added an id of respond to my article layout where the comments section starts.
  2. Updated my all-content and article feeds to add a comments tag where the post type is an article — with a value of that post’s permalink appended with #respond (internal page link).
  3. Bonus: implemented native browser smooth scroll by adding scroll-behaviour: smooth; to the body style block in my stylesheet.

Then I tested it, and… no luck! 😢

Moving from Atom to RSS 2.0

Turns out, the core Atom specification doesn’t have anything that resembles what is the comments tag in the RSS 2.0 spec.

The fool that I am, I began the process to move from Atom to RSS 2.0 because I really like silly stuff like that, and I also like to kill my time with stupid stuff when I could be living the “real” life.

Because my feeds setup is not yet DRY, it took me over 2 hours to carefully piece everything together for all seven of my feeds.

In this process, I learned a lot about how to write an Atom feed vs how to write an RSS 2.0 feed. Despite the time spent, the effort was well worth it and a very educational journey.

Now the ‘Comments’ link shows for my articles and is an added incentive for a reader to drop by and say hello — quickly.

A screnshot from my Miniflux app which now shows an article from my feed carrying the Comments link

Here’s some thoughts on this transition, generally including data that wasn’t present before in the old Atom feeds (but not necessarily):

Description

I added a description tag to items so if I have set a meta description for any post (article or otherwise), RSS readers can pick that up as an authoritative preview of the post instead of generating a post summary from its content, then cutting it short and making for a fussy experience for the end-user.

Categories

I’m not sure what adding a bunch of category tags does in an RSS feed. It doesn’t seem to make any visible difference on Miniflux in my basic testing.

Do you know what purpose it serves? Please let me know in the comments.

Last Build Date and Publish Date

RSS 2.0 also offers lastBuildDate and pubDate tags.

These are similar to Atom’s atom:updated tag.

lastBuildDate and atom:updated appear to me to be slightly different in meaning based on their labels and descriptions, but there are arguments that they’re the same. Or different. Or same. Who knows? See discussion on StackOverflow. I like the answer by Chris Pratt.

At the channel level, his explanation is what I’m going with. pubDate may represent either the date-time the last post was published or modified. lastBuildDate refers to the date-time the feed was last created and made available online.

I still have confusion around whether the pubDate at the item level should update if the article is updated.

Still, at the item level, I have decided I am going to use pubDate and set it to the post modified date if available, falling back on the original post publish date — similar to what I’m doing at the channel level with this tag.

Managing Editor and Web Master

RSS 2.0 also offers a couple of interesting optional properties on the channel elements: managingEditor and webMaster.

Miniflux appears to use this info on the post page:

A screenshot from my Miniflux app showing the post entry page with the post title, action buttons such as: Read, Comments, Fetch Original Content, etc. It includes an additional data item now: the author's information.

You can observe that my email and name are clearly displayed for anyone to contact me directly if they have any concerns. This was not so in my Atom feed despite specifying the author information.

Date formats

While my Atom feed was happy with ISO8601 dates, the W3C feed validator was not happy with this when I moved to RSS.

Turns out RSS needs an RFC822 date.

I use the date-fns library and unfortunately it does not offer a format function for this spec. However, it did offer RFC7231 and RFC3339. A cursory look at both and it seemed to me RFC7231 might work. Which it did, and now all my feeds pass W3C validation.

That’s all folks.

I’m now an (almost) happy RSS 2.0 camper. 😊

I was told Atom is the “superior” standard — which it may well be — but I find RSS 2.0 more suitable for my goals. So, here we are.

0

Comment via email.