Atom beats RSS on title encoding, new essay argues
The author of chrismorgan.info publishes a draft essay making a narrow, concrete case that Atom is technically superior to RSS, distinct from the usual purity argument. The author states plainly that everyone with knowledge already agrees Atom is better and that the switch should have happened twenty years ago, and says nearly all feed readers support Atom fine already. The essay dismisses most commonly cited RSS flaws as surface level: the awkward date format barely affects anyone, and the long-standing ambiguity over whether the description field holds plain text or HTML has effectively been settled in practice, since everyone now emits and assumes HTML. The one difference the author says genuinely matters is title encoding. In RSS, titles cannot reliably carry characters like < or & or any HTML markup, so a heading such as an article about the xmp element has no safe way to be written. Atom fixes this with what it calls a text construct: a title can be explicitly marked as type text, type html with entities encoded, or type xhtml with the markup represented directly as XML, giving publishers three unambiguous choices instead of one guess. Partway through this section, the author admits the essay probably should have been published around 2020. The author says a second difference, the distinction between an item's summary and its full content, also favors Atom, though the essay does not spell out the mechanics of that point. It also admits to having forgotten a third difference it meant to include. The essay's other major thread is podcasts, which the author calls the fly in the ointment. Despite Atom's technical edge, most of the largest podcast feed readers and syndicators still support only RSS. The author traces this to Apple: iTunes podcasting support only ever handled RSS, the iTunes client picked up Atom support at some point but the iTunes Music Store did not, and the author says no clear evidence was found that the store, later renamed the Apple Podcasts catalogue, ever supported Atom at all. Whatever partial support existed was removed in 2023. The author lays blame on Apple for controlling the podcast space in its early days and calls the resulting podcast RSS ecosystem a mess, frozen in time and patched with workarounds. The piece is explicitly marked as a draft in progress and closes on that podcast complaint rather than any further admission.
Key facts
- A draft essay on chrismorgan.info argues Atom is technically better than RSS specifically because RSS titles cannot safely contain characters like < and & or any markup.
- Atom fixes this with a text construct: titles can be marked type text, type html (entity encoded), or type xhtml, giving three unambiguous encoding choices.
- The author dismisses RSS's date format and content encoding ambiguity as mostly harmless in practice, since the ecosystem has settled on treating content as HTML.
- Despite Atom's technical edge, most major podcast feed readers and syndicators support only RSS.
- The author blames Apple: iTunes podcasting only ever supported RSS, the Music Store never clearly supported Atom, and whatever partial support existed was removed in 2023.
Why it matters
The essay isolates a narrow but real gap in RSS: it has no defined way to safely embed HTML markup, such as code or emphasis tags, inside a feed item's title. Content management systems routinely let headings contain markup but rarely extend that to titles, so authors who want a tag name or emphasized word in a headline have no reliable, standard way to encode it in RSS. Atom's text construct closes that gap by letting a title declare itself as plain text, entity encoded HTML, or XML encoded HTML, so a reader always knows how to interpret it.
Who it affects
The people who feel this are blog and CMS authors who write technical headlines containing code or markup, and the developers of feed readers and parsers who have to guess how to handle ambiguous RSS titles. Podcast listeners and creators are affected differently: the essay argues the format fight barely touches them, since nearly every major podcast reader and syndicator still works only with RSS no matter which format is technically superior.
How to use it
For publishers who want unambiguous titles with markup, the essay's implicit recommendation is to publish Atom feeds rather than RSS, using the type attribute on the title element (text, html, or xhtml) to state exactly how the value should be read. It does not recommend any change for podcasts, since the author found no evidence that the dominant podcast catalogue, previously the iTunes Music Store, ever supported Atom, and whatever support existed elsewhere was pulled in 2023.
How solid is it
The piece is a first person, self-published opinion draft, explicitly labeled as a draft still in progress, not a formal standards analysis. Its central technical claim, that RSS titles lack encoding semantics while Atom's text construct defines three explicit options, is stated as a specific, checkable fact rather than a vague preference. The author is candid about the essay's limits: a planned survey of how real RSS readers handle ambiguous titles is listed as an unfinished TODO, and the author admits to forgetting a third intended point entirely.
Risks and caveats
This is one person's technical argument, not an industry consensus or a standards body finding, and the author's sweeping claim that everyone with knowledge already agrees Atom is superior is itself unverified. The essay's own text never states the author's name, though the personal domain it is published on implies who wrote it, and it gives no organizational affiliation. Its account of why podcast platforms never adopted Atom rests on the author's own research into Apple's history rather than on any statement from Apple, and the essay openly concedes gaps, including the missing reader survey and the forgotten third point.
“I want RSS dead.”
— the essay's author