RSS is solid. It’s lasted a long time with very few changes, and forms the foundation for subscribing to weblogs and delivering podcasts. It’s huge and the open web is a much better place because RSS exists.
But even if RSS doesn’t need to change, some types of apps would be better off if we took a fresh look at the elements in an RSS feed. What is really needed, and when faced with multiple “correct” options, which should we choose? As more writers embrace microblogging, it’s an opportunity to simplify our feeds and tools.
This is my proposal for a bit of housekeeping around microblogging. It’s not a new format. It’s just a guide for producing the best RSS. I’d divided this proposal into 5 sections below.
Minimum viable elements
Look at the average RSS feed and there’s a lot of junk in it that most RSS readers ignore. While there’s nothing wrong with including extra XML elements, we should strive for a feed that is simple enough to be easily read. The fewer redundant and unused elements, the more consistently that different RSS readers will interpret it.
Here’s an example of an RSS feed whittled down to its essential elements. Most feeds should look like this by default, and only add additional elements from the RSS spec or RSS extensions when it’s absolutely required (such as the enclosure element for podcasting).
<rss version="2.0">
<channel>
<title>Manton Reece</title>
<description>Manton's weblog.</description>
<link>[www.manton.org/</titl...]([www.manton.org](http://www.manton.org/)</title>)
<item>
<title></title>
<description><![CDATA[
<p>Hello world.</p>
]]></description>
<pubDate>Fri, 04 Sep 2015 15:32:32 +0000</pubDate>
<guid isPermalink="true">[www.manton.org/2015/09/3...]([www.manton.org](http://www.manton.org/)2015/09/3007.html</guid>)
<link>[www.manton.org/2015/09/3...]([www.manton.org](http://www.manton.org/)2015/09/3007.html</link>)
<author>@manton</author>
</item>
<item>
...
</item>
</channel>
</rss>
Title is optional
The existing RSS spec says that title is optional. In fact, in the early days of blogging, tools such as Radio Userland and Blogger didn’t even have titles. We got away from that with the popularity of Movable Type and WordPress, even though some modern apps like Tumblr still look at a title as unnecessary for certain post types.
With microblogging, the title will frequently be empty or missing. Do tweets have titles? No, and neither should short microblog posts published through a traditional blog platform. Skipping the title removes some friction in the writing process, making it easier to write a quick post and send it out.
RSS readers must be prepared for a title-less RSS item. Instead of inserting “Untitled” as the placeholder title, think about how your reading UI can accommodate microblog posts gracefully. Blank titles (where the title exists but is an empty string) are equivalent to a completely missing title element.
HTML post text
The description XML element in RSS wasn’t originally intended to support HTML. It was often a text summary or opening paragraph of an article, rather than full text. With microblogging, you always want the full text inside the RSS feed, including any styled text or inline HTML links.
Some feeds will include the plain text version of a post in the description element, and the HTML version in a content:encoded element, as specified by this RSS namespace extension. This should be avoided in favor of a single description element with the full HTML, using CDATA syntax to avoid escaping characters.
In modern apps, rendering simple HTML is common. If an RSS reader can’t show HTML, it should strip out the HTML tags itself. It’s not up to the feed to provide multiple versions. If both description and content:encoded are present in a feed while parsing, for compatibility it’s acceptable to prefer whichever includes HTML.
JSON
I said this isn’t a new format, but we should have the option of expressing RSS in JSON instead of XML format. Back in 2012, Dave Winer wrote about producing a JSON-based RSS feed, with a very literal mapping of elements. If our goal is to cleanup some of the edge cases of RSS, though, we can further simplify it. I’d suggest collapsing a few of the elements, so that it isn’t overly nested like XML, and to JSON-ify the item elements into a simple items array:
{
"channel": {
"title": "Manton Reece",
"description": "Manton's weblog."
"link": "[www.manton.org](http://www.manton.org/)"
},
"items": [
{
"title": "",
"description": "<p>Hello world.</p>",
"pubDate": "Fri, 04 Sep 2015 15:32:32 +0000",
"guid": "[www.manton.org](http://www.manton.org/)2015/09/3007.html",
"link": "[www.manton.org](http://www.manton.org/)2015/09/3007.html",
"author": "@manton"
}
]
}
This preserves the element names and overall feel of RSS, while being cleaner and more JSON-like. Note that it’s easy to embed HTML directly in the JSON description field. Because there’s no room for an isPermalink attribute, if the guid is a URL, it is always the permalink.
Authors
A feed for a microblog platform, or a group weblog, might include multiple items each from different authors. The RSS spec says that the XML “author” element is an email address, but that is very rarely used in real feeds.
Instead, the author element value should vary slightly from the original specification to include either a simple full name, or a username prefixed with the @-sign: <author>Manton Reece</author> or <author>@manton</author>.
What do you think? I’d love to hear any feedback via email. If you write on your own blog about this, send me the link.
