Attenuating the Web

For some time now I’ve been thinking about how our RSS¹ feeds homogenize the web. Web standards have grown over the past few decades to provide us with more interactivity and more room for expression, but most feed readers strip all of this away. I’ve written before about my ambivalence towards RSS, how reading blog posts from friends in my feed reader denudes their beautifully designed websites of nearly all personality. In the intervening two years I’ve begun to notice more ways in which feed readers limit our ability to express concepts through our designs. If we are publishing a feed, we have to be cognizant of the limited semantics that feed readers are likely to present readers.

Let me offer a concrete example. I like to have little digressions sprinkled throughout my posts in between paragraphs. These digressions are usually offset from the surrounding text visually with indented margins and smaller text and maybe a background color. Per Ben’s advice and example, I use role="note" in my HTML to denote these digressions. This attribute tells the browser that the contents of the element are parenthetical … to the primary content (WAI-ARIA 1.3) — in other words: a digression. The attribute also makes it easy for me to style the digressions to communicate their parenthetical nature to sighted readers using an attribute selector, [role="note"], in my CSS. But feed readers don’t load CSS, so my digressions will look exactly the same as the surrounding paragraphs; any sense that these paragraphs are different in kind is lost.

To solve this problem for feed readers, I add a <small> tag to the markup because it has default styles that feed readers can be relied upon to preserve (and I’m pretty sure it’s semantically appropriate in this instance, even if it’s superfluous with the role). So the full markup for one of my digressions looks like <p role="note"><small>...</small></p>. Ben, on the other hand, transforms the HTML from their posts before putting it into the RSS feed to replace the role="note" wrappers with a <blockquote> because feed readers reliably style <blockquote>.

These workarounds irk me because they seem unnecessary. As far as the semantics of HTML are concerned, role="note" should be sufficient to communicate the meaning of these digressions. CSS gives us the tools to visually communicate these semantics to sighted readers, despite lacking any default browser styles. And yet feed readers provide no mechanism to communicate these richer semantics that are now available to authors on the modern web.

Feed readers reduce the set concepts that can be expressed on a website to a small, arbitrary subset of concepts that a writer might want to use in their writing.

Footnotes are another concept with which feed readers seem to struggle.² Feedbin does actually try to represent footnotes in a useful way. Typically footnotes are implemented as links that take you down to the bottom of the page, and then (ideally) provide a link back to the spot where you left off. If Feedbin detects what it thinks are footnotes, it will present you with a button that when activated will display the footnote text in a popover, rather than jumping around the page with links.

Great! But sometimes it doesn’t detect footnotes properly, I’m not really sure why. In that case it falls back to treating these like links, which opens the original page for the post and jumps down to the bottom of the page where I can continue reading. On the one hand, this is a perfectly serviceable fallback; on the other, I find it jarring.

And footnotes are but the tip of the proverbial iceberg that is interactivity on the web. The web is a rich medium for communication, allowing us to create dynamic, interactive interfaces to accompany our prose and our static images. But any interactive elements — be they <iframe>s, web components, or perhaps even animations tied to your progress through the page — are stripped in our feed readers. Feed readers don’t load and run JavaScript from our websites (probably for the best), and <iframe> is not even permitted in a feed (I know because the W3C validator scolds me for this).

Any post that contains a live demo or an explorable explanation can’t properly exist in our feeds. These posts can contain only an HTML fallback that informs readers they are missing out on the interactive elements. A mere shadow of what the web has to offer.

Having said all of that, I wouldn’t willingly give up RSS. But I find myself wondering: do we need an update to the feed specifications to reflect all of the changes in the modern web? Or perhaps we just need our feed readers to imagine a reading experience that goes beyond a chronological feed and a modern, minimalist version of browser default styles.

Some time ago I wrote about fraidycat, an RSS reader that doesn’t provide you with the typical chronological feed of all of the new posts in your feeds, but instead acts like a kind of smart bookmark system. Eschewing a chronological feed probably works better for following a digital garden, and reading on the author’s site allows their voice and personality, as represented by their design, to come through, as well as the full, unattenuated experience the web has to offer.

Perhaps we just need feed readers that radically reimagine the user interface to an RSS feed. I confess that have been considering trying to write my own feed reader.³

But that way lies madness.