phil ringnalda

Sam suggests that the RSS community discuss RSS practices that, while perfectly valid, are not a good idea, with an eye toward adding warnings to the RSS Validator. It’s a very good idea, but not exactly what I want to talk about.

The RSS 2.0 item for Sam’s post is perfectly valid, correct, best practice RSS: the description element contains plain text, with the characters that XML requires be escaped escaped. The HTML for the item is in an entity-encoded content:encoded element. It’s just not possible to do better RSS than that, and it took me three aggregators and two browsers to read the item.

Because Sam was talking about HTML tags, the item includes samples of those tags. In the content:encoded element, the less-than and greater-than symbols are double-encoded, as &amp;lt; and &amp;gt;, so that when the XML is decoded they will be &lt; and &gt;, which a browser will then display as < and >. In the plain text description, they are single-encoded, as &lt; and &gt;, so that when the XML is decoded they will be actual < and > characters, ready for display by anything displaying plain text.

But here comes the problem: because RSS 0.9x/2.0 allows encoded HTML in the description element (and lots of people put it in RSS 0.9/1.0, too), there is no way on earth for an aggregator to tell the difference between Sam’s plain text with XML encoded < and > in sample HTML tags, and someone else’s HTML with entity encoded < and > around actual HTML tags. I’ve seen quite a few explanations for why people don’t like having HTML in description elements, but I don’t remember having seen any mention of the fact that, for anyone who ever posts sample HTML code, the description element is useless in any aggregator which displays feeds in a browser. Even in an aggregator which displays plain text rather than HTML, the description element will be deceptive, since a plain text aggregator needs to strip out anything which looks like entity-encoded HTML, even if it turns out to have been intended as sample HTML in plain text. Your discussion of the HTML <link> tag will have to be a discussion of the [blank] tag in a plain text reader.

There is a workaround, though it sadly involves ignoring poor description. The content:encoded element contains either entity-encoded or CDATA-escaped HTML: if your XML parser hands you <img src…> then you know it’s intended as HTML, and if it hands you &lt;img src…&gt; then you know it’s sample HTML. Unless we all swear off ever posting sample HTML, the only workable solution to the current ambiguity about single-encoded &lt; and &gt; in description is for all RSS producers (or at least all who might ever post sample HTML) to include a content:encoded element, and for all aggregators to use content:encoded rather than description whenever it’s present. A plain text aggregator should be able to get away with just checking for &lt; in the description, and only turning to stripping HTML from content:encoded if it’s present (an approach which isn’t likely to please a developer who only wants plain text in the first place, I’m afraid).

Luckily, many desktop aggregators already do support content:encoded. That’s where my luck ran out, though. Somehow (probably my own fault), I broke my copy of Radio’s support for content:encoded, so I got Sam’s item description, with the unclosed sample <a href…> interpreted rather than displayed. I tried AmphetaDesk, but although I think the version currently in CVS supports content:encoded, the currently released version does not, so it also displayed a clobbered description. On to Aggie, which as far as I know was the first one to support content:encoded in a release version. While Aggie did display the content:encoded element rather than description, Sam’s perfectly correct and valid use of <code> around his code samples caused Aggie’s default template, with its cool “display in a tiny font, and enlarge it onclick” feature, to overlap words while switching between the monospaced code font and the proportional font for the rest of the item. On to Aggie’s alternate template, which displays just the post title, with an arrow image to click to display the body of the item. Which, sadly, doesn’t seem to function in Phoenix. So, I started Internet Explorer for the first time in three days, and after three applications, a template change, and two browsers, finally was able to read Sam’s perfectly valid item.