Re: [rss-public] Overriding Core elements via extensions
- Sam Ruby wrote:
> Consider an RSS 2.0 item which contains only the following elements:I ran a couple of tests through my little aggregator collection and these
were the results:
Basically everyone supported content:encoded (except Thunderbird), almost
nobody supported atom extensions (except Sharpreader), and around half
supported xhtml:body to some extent (prefixed xhtml generally caused
problems). When they're mixed together in a single item, extensions are
usually chosen before the standard description element and when multiple
extensions are supported by an aggregator, the last one encountered usually
Aggregators tested: Blogbridge, Bloglines, BottomFeeder, FeedDemon,
FeedReader, Googler Reader, GreatNews, JetBrains Omea, Netvibes, Newsgator
Online, NewzCrawler, RSSBandit, RSSOwl, Sharpreader, Snarfer and
Bloglines, BottomFeeder, JetBrains Omea, Newsgator Online, NewzCrawler,
RSSBandit, Sharpreader and Snarfer all supported xhtml:body. Only Snarfer
interpreted markup when it was prefixed (i.e. xhtml wasn't the default
namespace), BottomFeeder never interpreted the markup regardless of whether
it was prefixed or not, and Bloglines failed to display any content at all
when the markup was prefixed.
When all the elements were included in the order you listed, Bloglines,
JetBrains Omea, Newsgator Online, NewzCrawler, RSSBandit and Snarfer
displayed xhtml:body, Sharpreader displayed atom:content, Thunderbird
displayed the description, and everyone else displayed content:encoded.
When the elements were included in reverse order, FeedDemon, NewzCrawler and
Thunderbird displayed the description element, Newsgator Online display
xhtml:body, and everyone else display content:encoded.
It's probably also worth nothing that everyone interpreted the markup
correctly when included in the description element although this wasn't
intended to be a markup test so the example used was as simple as possible.