Both and use WordPress un­der the hood.

They are a great ex­am­ple of how the de­ci­sion to use an es­tab­lished frame­work lends it­self to good prac­tices — with­out the re­quire­ment of an ex­ten­sive amount of ef­fort or knowl­edge from its users.

Case in point, take the fol­low­ing two en­tries 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 no­tice 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 of­fer com­ments.

To fig­ure out how I could add this for my ar­ti­cles too, I looked at Four Kitchen’s RSS feed and found a comments tag with a value that would link to the com­ments sec­tion on the page.

Quite sim­ple, I thought.

Here’s what I did next:

  1. Added an id of respond to my ar­ti­cle lay­out where the com­ments sec­tion starts.
  2. Updated my all-con­tent and ar­ti­cle feeds to add a comments tag where the post type is an ar­ti­cle — with a value of that post’s perma­link ap­pended with #respond (internal page link).
  3. Bonus: im­ple­mented na­tive 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 spec­i­fi­ca­tion does­n’t have any­thing that re­sem­bles what is the comments tag in the RSS 2.0 spec.

The fool that I am, I be­gan the process to move from Atom to RSS 2.0 be­cause I re­ally like silly stuff like that, and I also like to kill my time with stu­pid stuff when I could be liv­ing the real” life.

Because my feeds setup is not yet DRY, it took me over 2 hours to care­fully piece every­thing to­gether 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 ef­fort was well worth it and a very ed­u­ca­tional jour­ney.

Now the Comments’ link shows for my ar­ti­cles and is an added in­cen­tive 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 tran­si­tion, gen­er­ally in­clud­ing data that was­n’t pre­sent be­fore in the old Atom feeds (but not nec­es­sar­ily):


I added a description tag to items so if I have set a meta de­scrip­tion for any post (article or oth­er­wise), RSS read­ers can pick that up as an au­thor­i­ta­tive pre­view of the post in­stead of gen­er­at­ing a post sum­mary from its con­tent, then cut­ting it short and mak­ing for a fussy ex­pe­ri­ence for the end-user.


I’m not sure what adding a bunch of category tags does in an RSS feed. It does­n’t seem to make any vis­i­ble dif­fer­ence on Miniflux in my ba­sic test­ing.

Do you know what pur­pose it serves? Please let me know in the com­ments.

Last Build Date and Publish Date

RSS 2.0 also of­fers lastBuildDate and pubDate tags.

These are sim­i­lar to Atom’s atom:updated tag.

lastBuildDate and atom:updated ap­pear to me to be slightly dif­fer­ent in mean­ing based on their la­bels and de­scrip­tions, but there are ar­gu­ments that they’re the same. Or dif­fer­ent. Or same. Who knows? See dis­cus­sion on StackOverflow. I like the an­swer by Chris Pratt.

At the chan­nel level, his ex­pla­na­tion is what I’m go­ing with. pubDate may rep­re­sent ei­ther the date-time the last post was pub­lished or mod­i­fied. lastBuildDate refers to the date-time the feed was last cre­ated and made avail­able on­line.

I still have con­fu­sion around whether the pubDate at the item level should up­date if the ar­ti­cle is up­dated.

Still, at the item level, I have de­cided I am go­ing to use pubDate and set it to the post mod­i­fied date if avail­able, falling back on the orig­i­nal post pub­lish date — sim­i­lar to what I’m do­ing at the chan­nel level with this tag.

Managing Editor and Web Master

RSS 2.0 also of­fers a cou­ple of in­ter­est­ing op­tional prop­er­ties on the channel el­e­ments: managingEditor and webMaster.

Miniflux ap­pears 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 ob­serve that my email and name are clearly dis­played for any­one to con­tact me di­rectly if they have any con­cerns. This was not so in my Atom feed de­spite spec­i­fy­ing the au­thor in­for­ma­tion.

Date for­mats

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

Turns out RSS needs an RFC822 date.

I use the date-fns li­brary and un­for­tu­nately it does not of­fer a for­mat func­tion for this spec. However, it did of­fer RFC7231 and RFC3339. A cur­sory look at both and it seemed to me RFC7231 might work. Which it did, and now all my feeds pass W3C val­i­da­tion.

That’s all folks.

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

I was told Atom is the superior” stan­dard — which it may well be — but I find RSS 2.0 more suit­able for my goals. So, here we are.