Phil Ringnalda talks about the problem of HTML data being present in an RSS feed. He suggests modifying the way aggregators work and the way publishers publish in order to solve this problem. “The only workable solution [...] is for all RSS producers [...] 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 < 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).” This sounds dirty to me.
I experienced the same frustration (for different reasons) last month. It seems to me the most proper solution would be to implement Chuck Shotton’s suggestion, originally made for RSS 0.94.
By allowing a content-type attribute for description, content:encoded, and possibly even title, and by setting reasonable defaults (text/plain for title and text/html for content:encoded and description aggregators can make more informed choices about how to handle the data they are seeing. If an aggregator doesn’t know how to display a particular content-type, it can provide it ask the operating system (or browser) to display the information for it. If a publisher chooses to do so, it can make life easier on the aggregator by providing multiple description (for instance) elements with different content-type attributes. Caution should be taken, however, to ensure that this doesn’t break current aggregators.