When we first announced our Atom 0.3 feed we complained that we weren't sure which media type to specify within the type attribute of link elements pointing to documents served using content negotiation. In our case, some browsers get archived documents served as application/xhtml+xml; others get text/html. Two media types. One type attribute. Which should we use?
Dare Obasanjo forwarded our question to the Atom-Syntax mailing list (where we probably should have asked it in the first place).
<link rel="alternate" type="text/html" href="http://www.example.com/" />
<link rel="alternate" type="application/xhtml+xml" href="http://www.example.com/" />That is: the same href in both, the same @rel, but different @types.
With conneg, you can find multiple media types in the same location. Stating that xhtml can be found at a given URI does not imply that one can not find other representations at the same location.
What a link tag says is literally "you can find THIS media type THERE". This means that it would be quite valid to have multiple link statements with the same URI.
Eric, again:
In a perfect world the type attribute would be passed to whatever is being asked to retrieve the resource, and it would specify that type in it's http request as to what type of resource it wants back (ie. content negotiation).
As the #joiito regulars rehashed their thoughts on CSS in syndicated feeds, Joi Ito himself announced that he's styling his RSS feed (with help from Richard Soderberg). Many have noted that this doesn't work in some aggregators. Some are filing bug reports with their aggregator of choice. NetNewsWire developer Brent Simmons notes:
Some people think it's cool, others don't. I suspect an obvious feature request will be for aggregators to notice when this technique is being used and be able to turn it on and off.
That's a start. The consensus, it seems: strip inline styles (specified within the HTML/XHTML style element) and external styles (in external style sheet files), but allow styles specified within the style attribute. The truth: we don't want your styles.
Wes Carr's comments effectively synopsize our thoughts:
I think this is a mistake for several reasons. First, I see you use linking to import your css, which is required to be declared within the HEAD tag in html. The DESCRIPTION tag in RSS is equivalent to the body tag, so this is invalid markup.
Also, by using CSS you start catering to specific aggregators and go away from what RSS is all about: SIMPLE syndication. News aggragtors should allow users to customize layouts, like Feed Demon for example, instead of relying on the feeds.
Personally, I find it quite annoying to have my style preferences overriden by others.
Simple syndication. This is why we've been reluctant to apply any styles to our feeds. There are several (already discussed) reasons to style feeds for browsers, but no (good) reasons to send styles to aggregators. We may even want to use display: none; (like we're doing in our Atom feed) to hide sections of the feed from browser visitors. It'd be a disaster if aggregators applied this rule. And it'd at least be a visual disaster if they applied any other.
Oh yeah, happy holidays, and all that.
Update:
Anil Dash advocated styling feeds nearly a year ago. Tom Coates replied:
No! No! This can't be allowed to happen! We've tried over and over again to make a version of our sites that are completely open and visible to everyone - standards compliant and accessible. We finally have a different way of doing things that mean that you can read sites in a text-only format and we want to get RID of it!? This is insane! HTML e-mail was a stupid move that fulfilled no function. Newsreaders and RSS should be kept clean and pure and simple. Keep the web for displaying things in a published style. Let Newsreaders be plain text, please!
Many of you have argued that XHTML served properly -- as application/xhtml+xml, that is -- isn't practical for dynamic Web sites. Simon Willison calls it "living on a knife edge:"
This is no small step to take - serving XHTML with the correct Content-Type causes Gecko based browsers to attempt to parse it using a real XML parser, and should it turn out to be well formed they will refuse to render the site and die with an error message. Since I use Phoenix myself and almost certainly visit this site more than anyone else I'm hoping I'll spot and fix any errors before anyone else runs in to them. Talk about living on a knife edge!
We've argued that there are real benefits to using XHTML properly. Indeed, we still believe this. But anyone visiting our site today saw why it's dangerous to turn your site over to an XML parser. For a few hours, one of the links on our site included a description within the title attribute that contained a quotation. Un-escaped quotation marks are illegal within attributes. As a result, our site failed, in the full sense of the word. Anyone visiting today -- for the few hours before we caught our error -- saw only an XML parsing error.
Looks like we fell off the edge of the knife.
We haven't stopped believing in XHTML. But we can't help wondering a few things. What if this were our business site? What if downtime meant loss of revenue? Our readers -- we think -- understand the benefits of this experiment. Would a client interpret today's failure as anything but incompetence? Of course not.
As link logs wax ubiquitous, we're increasingly frustrated that many of you are placing your link commentary in the anchor tag's title attribute, like this:
<a href="http://example.com" title="Unbeatable link commentary here...">My Link</a>
Why? Our browser of choice -- the latest Mozilla release -- truncates long tooltip strings. We'd love to read the (not so) terse commentary that accompanies your daily links. We simply can't. Consider this: it's not a physical disability that's keeping us from your words -- it's you.
Mark Nottingham announces the release of The Atom Syndication Format 0.3. Mark Pilgrim provides valuable upgrade assistance. We've fully updated our feed to conform to the 0.3 spec. Most notably, our feed now makes use of the recently proposed <info> tag to display an explanatory message when viewed in a browser. We've chosen not to style individual entries.
Our Atom 0.2 feed is still available for comparison.
One particular change to Atom has left us perplexed. Previously, Atom <link> tags contained only a resource's address, with no attributes, like this:
<link>http://www.example.com/</link>
The new format requires the type attribute, which lists the target document's media type, like this:
<link rel="alternate" type="text/html" href="http://www.example.com/"/>
As regular readers know, we're serving our documents as 'application/xhtml+xml' to browsers that support it and 'text/html' to those that don't. There's no way to tell from our Atom feed which media type your browser will get. As a result, we're not sure which media type to use in our feed's <link> tags (or if it even matters). Let us know what you think.
Our host experienced server difficulties earlier today that resulted in disabled write access on our account. Two components of our site -- the blo.gs powered blogroll and del.icio.us powered link log -- require write access to work. Neither of these services were working today. The issue was entirely with our server, not with either service or the scripts that power them.
Incidentally, the outage did bring to light a shortcoming of our del.icio.us script's error-handling that we've now fixed.
del.icio.us.pl 0.1
del.icio.us.pl is a Perl script for displaying del.icio.us links on your Web site. The script was inspired by Paul Hammond's blo.gs.pl, which solves a similar problem.
Installation
Download the script and follow the instructions in the included "readme.txt." You'll need a Web server that allows you to run Perl scripts as CGI. You can also view the script online.
Original Announcement
The original announcement is below.
We're now using del.icio.us to power a link log in the menu bar of this site's main page. The script we're using is available to those interested. Documentation is forthcoming.
Instructions for installation are included in the .zip file.
Please send any comments, bug reports, or questions our way.
Scott Rosenberg: "...for the wider world of Salon's readers and beyond, RSS remains a novelty worth introducing with a fanfare." That may be, though we think Scott's criticism is the most interesting part of his piece at Salon:
RSS needs a better colloquial name. And easier, more intuitive interfaces for aggregators. And a simpler method for subscribing to feeds (right now you need to copy the URL from one of those increasingly ubiquitous orange "XML" buttons on a site -- if you click on the button, you'll just get raw XML in your browser, which confuses novice users no end).
Of course, there are ways to (1) make RSS more useful and attractive in the browser, and (2) automatically subscribe to feeds, though we recognize the latter as software-specific. Feeds like Dave Shea's -- which is styled using CSS and XSL, and which provides help to new users within the feed itself -- go a long way to ease at least one of Scott's concerns. Our only concern is that aggregators, too, will recognize and display styles, though we've no specific reason to believe this behavior exists. We'd prefer not to trade one usability issue (unstyled RSS in the browser) for another (unpredictable styling of RSS in the aggregator).