This topic seems to have resurfaced now that
Joi is putting this in his feeds and there even is a
howto...
like
Shelley and others, I've yet to be convinced that syndicating
CSS is appropriate, but on a purely technical level, here's a few
comments:
Richard's howto gives a different recommendation for how to
encode this data inside a content:encoded element for RSS 1.0 and
RSS 2.0. Given the way that most aggregators deal with
versions and RSS, I don't think that this is appropriate. The
recommendation given for RSS 1.0 is the correct one. I note
that Joi has followed the RSS 1.0 recommendation for both his 1.0
and 2.0 feeds.
The Atom recommendation is incomplete: whether the data needs
to be escaped or not would depend on the value of the
mode parameter.
Aggregators that combine content from multiple feeds into a
single page (examples:
Radio
Userland and
Aggie) will find it
quite difficult to handle item level CSS properly - and by default,
they will do the wrong thing. Note that by default, the Radio
Userland aggregator will ignore content:encoded, so this is less of
a problem.
SharpReader displays
the link tag that is present in Joi's feed verbatim instead of
interpreting it as markup.
Overall my recommendation is to not to try to tunnel this
information inside the content, but to place it outside the content
(either at the item or the feed level). This would make it
easier for aggregators to identify that a stylesheet is
desired and to take the appropriate action.
In Atom's case, the recommendation would be to simply place the
link tag at either the feed or specific entry level.
In RSS, I would also make a similar recommendation, perhaps
adopting the xhtml namespace.
A question I posed yesterday about Atom is what are aggregators supposed to do if they receive in-line content of a valid XML type (lets postulate a text/vcard+xml) for which there is no obvious mapping to HTML?
Joi's CSS messed up my aggregator so much that I dropped his feed like used Kleenex. It's a baaaaad idea; RSS is supposed to be about content, not form, IMHO.
I've applied your suggestions for both the RSS 2.0 and the Atom feeds, as well as indicating that the RSS instructions will change int he future, once a way is found to link the stylesheet outside the HTML. Thanks!
The current method does indeed trigger bugs in many feeds-in-a-page RSS readers, varying from SharpReader (Luke confirms that it doesn't handle the <link> tag) to Feed on Feeds (directly interpolates the <link> tag into the page). I've filed three bug reports for three readers, even though the current plan is to eventually lift <link> out of the HTML content. It does expose a problem where many readers don't sanitize the HTML they receive before displaying it, something Mark has talked about.
Many put a lot of effort into the look and feel of their website, and then watch it reduced to plain-looking HTML in RSS readers. After seeing Joi's feed reduced in this manner, I decided to try applying the rather elegant style from his site to...
Joi Ito recently added a link to a CSS style information to the content in his RSS feed. This broke a number of news aggregators because his stylesheet clashed with whatever styles were being used by various client aggregators. As Sam Ruby ...
Adrian & Sam,
I suspect it will be a competitive advantage for aggregators that to support as many MIME types as possible. For example, text/vcard+xml simply becomes a link or button that says "Add this to my contact list". Of course, this means having to figure out what apps the user has installed so that you can call out to the right applications.
Heh, I'm going to have to start digging into the Outlook object model pretty soon.
I just got a 500 when trying to post the following comment from RSS Bandit
<item>
<title>RE: Syndication and CSS</title>
<link>http://www.25hoursaday.com/weblog</link>
<pubDate>Wed, 31 Dec 2003 09:02:45 GMT</pubDate>
<description><![CDATA[Adrian & Sam,
I suspect it will be a competitive advantage for aggregators that to support as many MIME types as possible. For example, text/vcard+xml simply becomes a link or button that says "Add this to my contact list". Of course, this means having to figure out what apps the user has installed so that you can call out to the right applications.
Heh, I'm going to have to start digging into the Outlook object model pretty soon. ]]></description><author>kpako@yahoo.com (Dare Obasanjo)</author><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">kpako@yahoo.com (Dare Obasanjo)</dc:creator></item>
I have a really hard time understanding what RSS/Atom + CSS gets you that XHTML/CSS doesn't. Push lives on? All you're doing is substituting one browser for a new, more highly specialized browser. Sounds like re-inventing the wheel to me.
That being said, XML + CSS in any form is interesting, and the above argument could be made for other applications of it as well. So who knows, maybe I'm just not seeing all the pieces of this puzzle.
Bloglines strips out link tags, along with a bunch of other stuff, to prevent various kinds of attacks. Not saying that including a stylesheet in RSS is necessarily an attack. But bad things can be accomplished with them.
I would think CSS with RSS is probably a bad idea, as there isn't any systematic way of handling it, so what is a poor agent to do?
Personally I'd be happy to see links to CSS included in Atom feeds, assuming their use was standardised (and Mark writes the tests...)
But I don't think I'd ever have per-feed CSS styling switched on in whatever aggregator I was using. If I want fancy visuals, I'll use a regular browser. If I want to skim a lot of blogs, the (minimally marked up) text is best.
CSS in a syndication feed is NOT a bad idea. In fact, layout can be just as critical to effective communication. I second Sam's suggestion of putting the CSS information at the feed level, and let the client side decide what to do. I also suggest that powerful news readers like NNW can let the end user turn on and off CSS support on a feed-by-feed basis.
I’ve been getting email asking what I think about CSS in RSS, in light of Richard Soderberg’s how-to, Joi Ito’s use, and Sam Ruby’s guidance. I have a few thoughts: 1. Some people think it’s an abomination. Other people...
I suppose that if you want to allow CSS in news posts safely in an aggregator that puts multiple stories on a single web page, you would need a CSS parser.
Parse the CSS associated with the article, and apply it to the article by adding style attributes to the appropriate elements. This would make sure that the style information from one post won't interfere with the style information from another post. It would also make it a lot easier to filter out evil CSS, such as absolute positioned elements, things like background:url("javascript:alert('foo')"), or IE extensions such as eval().
If this sounds like a lot of work, then stripping the style info completely is probably the best option. A halfway measure will almost definitely have a hole in it that someone can workaround.
It seems inevitable that CSS will be present in RSS. As a user of a single page aggregator, I suspect that I'm going to be in the experimental front line. Please use CSS to make your ideas shine, not display your graphical wizardry. When I visit your website, I'm visiting your office. But when I subscribe to your feed, you're invited into my house. Try to play nice....
[more]
This topic seems to have resurfaced now that Joi is putting this in his feeds and there even is a howto... like Shelley, I've yet to be convinced that syndicating CSS is appropriate, but on a purely technical level, here's a few comments ... [Sam...
brisingamen says "Meme! You're it." My journal is called __ because __. "The Marsupial Tool Chain FAQ" Inspired by a comment made by Mark Pilgrim on Sam Ruby's weblog: "Do not trust your upstream platypus." The subject was security in processing...