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):
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:
- Added an id of
respondto my article layout where the comments section starts.
- Updated my all-content and article feeds to add a
commentstag where the post type is an article -- with a value of that post's permalink appended with
#respond(internal page link).
- Bonus: implemented native browser smooth scroll by adding
scroll-behaviour: smooth;to the
bodystyle block in my stylesheet.
Then I tested it, and... no luck! 😢
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.
Here's some thoughts on this transition, generally including data that wasn't present before in the old Atom feeds (but not necessarily):
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.
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.
RSS 2.0 also offers
These are similar to Atom's
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.
RSS 2.0 also offers a couple of interesting optional properties on the
Miniflux appears to use this info on the post page:
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.
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.