Draft: started •
My feeds are Atom feeds.
Everyone with knowledge agrees that Atom is technically superior to RSS.
Everything should have switched to it twenty years ago.
All feed readers support Atom just fine (except in podcasts, for no good reason).
Unfortunately, many people continued to write and choose RSS,
whether from ignorance of Atom (please stop calling feeds “RSS”!),
or from figuring it doesn’t really matter in the end.
Most of the differences are surface-level, or in practice not a problem:
- RSS uses a stupid date format? Doesn’t really affect people much.
- RSS doesn’t specify content encoding, so it’s ambiguous as to whether
<description>is text or HTML?
Used to be a problem, but these days everyone emits and assumes HTML.
In fact, RSS 2.0 specs settled on it being HTML,
though people often use the unreasonably-popular, wonkily-versioned, horribly-namedcontent:encodedto mean that, even though that’s not what it was supposed to mean. - RSS is a travesty and the name refers to nine mutually-incompatible formats, published by a variety of different and competing organisations sometimes even using the same version numbers?
Meh, just ignore the XML namespaces, be sloppy,
the feeds you want to cope with will be worse.
Resign yourself, it’ll be easier in the long run.
Seriously, you may even be able to get away with forgetting that RSS is supposed to be XML.
But what few realise is that some of the differences matter.
That due to inconsistent treatment and usage,
some reasonable content cannot reliably be expressed in RSS,
whereas it’s unambiguous in Atom and should always work fine
(and if it doesn’t, it’s unambiguously a bug).
So let’s talk about the cases that matter. Précis: you can’t reliably use characters like Content management systems normally allow headings to contain markup; Atom defines something called text construct, In RSS… well, not even content gets encoding semantics, Suppose you want to encode this title: How are you going to do it? In Atom, you have three clear choices: TODO: survey RSS readers to find out how they handle all of these cases. Hard mode challenge: RSS bad, Atom good. Capiche? 😁 Heuristics, bad for interop, &c. &c.
I would like to convince people to prefer Atom for useful reasons,
rather than merely ideological purity.
I want RSS dead. Title encoding semantics
< or & in RSS titles.
Don’t even try mentioning HTML tags in titles.
but they seldom allow titles to contain markup.
This is a tragedy. Many an article calls for <code> or <em>.
I do it often, and I’ve seen a few others do it, but not many.
where you can specify whether the value is text,
entity-encoded HTML, or XML-encoded HTML.
Titles are text constructs.
which used to be a real problem,
but over time everyone settled on “it’s always HTML”.
So titles definitely don’t get encoding semantics.
And different implementations do different things. All about the
<xmp> element
<title type="text">
All about the &lt;xmp> element
</title> <title type="html">
All about the &lt;code>&amp;lt;xmp>&lt;/code> element
</title> <title type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
All about the <code>&lt;xmp></code> element
</div>
</title>
(This is the biggest reason I haven’t published this previously. Probably should have by 2020 or so.) <_>::v::<_>, a real title I used. The summary/full item distinction
I feel like there was a third Difference that Matters that I had in mind at some point. Maybe I’ll remember it before I publish. I must, in good faith, mention podcasts. Since this stuff is largely from 20–25 years ago, Rough timeline: So I want to blame Apple. RSS is a mess. Podcast RSS is even more of a mess. The fly in the ointment: podcasts
Although approximately every single feed reader and open-source feed-reading library
from the last twenty years supports both RSS and Atom,
most of the largest podcast feed readers or syndicators only support RSS.
and I wasn’t paying attention to the space at the time (few twelve-year-olds would),
details are hazy.
Podcasting started to be a thing.
RSS 2.0 added enclosures for it.
Atom was designed, to fix most of the problems with RSS.
It stabilised.
Apple released iTunes podcasting stuff only supporting RSS.
The iTunes client got Atom support, but the iTunes Music Store did not.
Atom was published as RFC 4287.
I have found no clear evidence that the iTunes Music Store
(later the Apple Podcasts catalogue) ever supported Atom.
And whatever iTunes/Apple Podcasts ever did have, was removed in 2023.
They controlled the space in the critical early days, and they ruined it.
Some podcast readers or syndicators support Atom.
Some claim to but don’t.
Some (probably the most important ones) just don’t.
Frozen in time, hack is piled upon hack to work around RSS’s shortcomings.
Ugh.