IE7 gives you a really quite nice view of an Atom feed. Take a look at the one for this blog, for example. You can filter by category, sort by date or title or author, and search for particular words or phrases. Pretty neat.
But it’s only a partial implementation. I’ve been having to create some Atom feeds recently, and getting them to display nicely in IE7 has proven a bit tricky. I couldn’t find any documentation about this with a quick google, so thought I’d blog it for future reference.
The main things are:
Do not use a prefix for the Atom namespace. IE7’s Atom support is not namespace aware. (I gather this is a problem in a lot of Atom readers. Sigh.)
If you don’t embed the content in the entry then it will display the summary; to get a clickable link to the content, you must provide a <link> element whose href attribute points to that content. The <link> element mustn’t have any other attributes on it, so don’t add rel="alternate" or type="application/xhtml+xml". Having a src on <content> will not give you a link.
If you want to support viewing the feed in IE6 as well, you need to provide a stylesheet to transform it into something nice. As long as the feed is served as XML, IE6 will interpret an <?xml-stylesheet?> PI correctly, and both IE7 and Firefox will ignore it (which is probably what you want, since both Firefox and IE7 have decent native rendering of Atom).
Comments
Re: Incomplete implementations #1: Atom in IE7
So now I know why my feed doesn’t work in IE7 - thanks. :) The problem is, the feed items won’t display in IE6 (or Firefox 1.5) if I remove the namespace prefix, and I have an XSL stylesheet linked…if you could have a quick look at the code an see if you can figure out what’s going on - http://forums.overclockers.co.uk/showthread.php?t=17831694 - I’d really appreciate it.
Re: Incomplete implementations #1: Atom in IE7
The use of the default namespace in the Atom feed means that the
<feed>,<entry>etc. elements are in the Atom namespace.In your stylesheet, you’re doing:
When you select elements in XSLT, if you don’t give a prefix for the element then the processor will only look for elements in no namespace. So in this case you’re selecting
<feed>elements in no namespace and their<entry>element children (in no namespace again).You already have the Atom namespace declared in the stylesheet with the prefix
atom. The solution is simply to use that prefix whenever you refer to an Atom element:Re: Incomplete implementations #1: Atom in IE7
Brilliant, that makes complete sense. You’re my hero of the day - thanks!
Re: Incomplete implementations #1: Atom in IE7
That’s hardly surprising, considering that having a
srcon non-emptyatom:contentelements is not valid. RFC 4287 allows the attribute only on emptyatom:contentelements. Note also that the attribute has a completely different meaning fromatom:link[@rel="alternate"]/@href. It is strictly for out-of-line content.Re: Incomplete implementations #1: Atom in IE7
I know that you can’t have a
srcon<content>with content. What surprised me was that IE7 didn’t give a link to that content when it was referenced from an empty<content>with asrcattribute.I thought, from the spec, that the
<content>would hold or reference the real content and<link rel="alternate">would reference an alternative representation of the content (with a different content type or language). If I’ve got that right, it seems weird to ignore the reference to the real content and only reference an alternative representation of it.Re: Incomplete implementations #1: Atom in IE7
Ah. It sounded remotely as though you expected
atom:content/@srcto behave like a permalink. Sorry for the confusion.Indeed, the fact that IE neither attempts to load that content nor provides a link to it is indeed an omission. It’s in good company there, though – almost every aggregator is likewise neglectful.