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.
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.
Mark Pilgrim doubtless knows the answer to this question.
what about posting a few examples, describing desired result, and having people throw their RSS readers at them and see what happens?
Good point. I updated the feed to have both.
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?
This is what I would do; niche users don't get ignored, but they don't get to mandate how the circus is run either.
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:
http://www.rssboard.org/rss-profile-1#namespace-elements-content-encoded
http://validator.w3.org/feed/docs/warning/NeedDescriptionBeforeContent.html
http://thresholdstate.com/threshold/4166/conventional-rss
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."
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.
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.
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?
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.