RSS 2.0 question

Let's say you have an RSS feed and some consumers of it would prefer full entries of text/html content, but some would prefer full entries of text/plain content. Is the thing to do to put the text/plain in <description> and the text/html in <content:encoded>? Or will that cause some consumers to "accidentally" display the text/plain when they should be displaying the text/html?

Or should the two fields be <content> and <content:encoded> instead? (Does <content> even exist?) All the documentation says <description> should be an abbreviated summary, but I see nothing that talks about how to achieve that which MIME calls multipart/alternative.

(Just trusting the text/plain consumers to strip the tags out of the HTML to display it is suboptimal; the two versions should be formatted slightly differently to be most readable.)

Update: Ok, I changed the feed to contain both text/plain and text/html versions. Please try that in your favorite feed reader, and let me know if it screws up. A screw-up would be: it's showing you plain text when it could be showing you HTML.

Tags: , , ,

12 Responses:

  1. This is where Atom makes sense and RSS doesn't. Dave Winer's rants to the contrary, it is important that there are clear standards on this kind of stuff. Otherwise the various reader implementations can do what they want because the behavior is 'not defined'; community standards be dammed.

    However RSS is the de-facto winner adoption-wise. More proof, if you need it, that technical excellence counts for little against the power of an existing user base.

  2. Mark Pilgrim doubtless knows the answer to this question.

  3. baconmonkey says:

    what about posting a few examples, describing desired result, and having people throw their RSS readers at them and see what happens?

  4. xthlcm says:

    Why do you need both in one feed? Why not make the default something reasonable (like text/html) and then generate a second feed for those who want text/plain?

  5. deus_x says:

    I'd say that for plain text, followed by for the HTML is a good bet - the order appears to matter. And the "thing to do" if you're really worried is to try it in a few different readers and see what happens. This scenario in RSS isn't actually defined as such and so interpretations vary.

    For what it's worth:

    • deus_x says:

      Seriously? I can't type those tags in LJ comments? Man. Anyway, errata:

      "I'd say that <description> for plain text, followed by <content:encoded> for the HTML is a good bet."

  6. happypenguin says:

    Are there any stats on what percentage of users cant grok Atom? I can't remember the last feed consumuing app I used that didn't understand it.

  7. vsync says:

    I put it into stock Gnus v5.10.7 using the default settings and I end up with the raw HTML code displayed as text. I have MIME alternative buttonizing on, and text/plain as the default. It starts with text/plain selected, but that shows the HTML code as I mentioned. When I select text/html it renders cleanly. I'm using emacs-w3m for my HTML rendering, if that matters.

    • jwz says:

      Not that I care even a little bit about GNUS, but is this stupid behavior different, or did it do that with the old feed too?

      • vsync says:

        I never tried with the old feed. If there's a sample copy of its format somewhere I can try it and get back to you.