View this snapshot of my Atom feed in a real browser, where by real, I mean Mozilla-based. (That’s not fair; it works flawlessly in the latest version of Opera too.) You should get a page that looks very much like the rest of my site, with a friendly little blurb at the top explaining a little about syndication and what this feed thing is that you just clicked on.

This is not an original idea; Blogger does something similar for all of their feeds. In fact, the blurb at the top is the info element, which was originally proposed by Jason Shellen, a Blogger employee, and later refined in Atom 0.3 to make the content model match other Atom elements. Their blurb points users to the Blogger Knowledge base, which seems reasonable. The wording of mine is open for discussion.

What is new here, I believe, is the use of inline XHTML (properly namespaced, of course; this is still a valid Atom feed) to add a few other things to the page for browser users. The page header is a series of <div>s (the images and positioning are entirely defined in the associated CSS file, just like the rest of my site), and the breadcrumb trail is also a piece of hard-coded XHTML wedged in the middle of the feed in the appropriate place.

I have tested this with a number of Atom-enabled aggregators, and none seem to have any problem with it. Let me know if your Atom-enabled client misbehaves.

Note that the display doesn’t look right in IE/Win. I am shocked, shocked. Also, the links don’t work in IE (the breadcrumb trail should be clickable except for the last bolded link, and the letters in the page header should be clickable).

Instead of styling XML with CSS, another potential solution would be to associate it with an XSLT transform and let the client convert it to HTML. This would probably solve the cross-browser-CSS problem, since I could just transform it into exactly the same markup I use elsewhere throughout my site. It would also create all new, even more exciting problems in trying to create cross-browser XSLT.

Update:

The entry titles aren’t links in any browser, but they’re not meant to be. Some have suggested they should be, but I disagree. I don’t want to make this page *too* useful in a browser. I do not, for instance, want people visiting this page all the time in their browser. I just want to make it friendlier to first-timers (or accidental click-throughs) than dumping raw XML. The one and only goal of the page is to get visitors to subscribe to the feed in a feed reader.

Others have noticed that I’ve switched from application/atom+xml to application/xml to get this demo to work. Yeah, that sucks. application/xml is correct, in the sense that it’s not wrong. It’s not optimal, but at least it’s not text/xml. Oh God, let’s not have that discussion again.

I’m surprised no one has pointed out the irony of my using inline XHTML at all, given my strong and well-publicized opinion of XHTML for general use. In fact my HTML is virtually XHTML anyway, except for unclosed <img> tags. I may employ some quick regular expressions and inline XHTML for the full content in my feeds, since Atom supports that and all Atom-enabled aggregators I’ve seen support that. As I’ve mentioned before, this is the only real use I’ve seen for XHTML. And then I could display the full content on my styled-for-browsers Atom feed. (Sam does this.) Not sure if that would be an improvement worth making.

§

Seventeen comments here (latest comments)

  1. I’m getting a horizontal scrollbar in Firefox.

    — Radley #

  2. It’s not displaying anything in Safari 1.2.1 either, for whatever that’s worth. Looks really nice under Firefox, though.

    — Dan Dickinson #

  3. Having always objected to anything that stands between me and viewing a raw feed, because I only do it to debug someone’s problem, I’m glad I’ll never need to help you debug a feed problem :)

    I take it this is just a stop-gap measure, until aggregators start registering as handlers for application/atom+xml?

    (I can’t believe I killed a kitten to leave that comment.)

    — Phil Ringnalda #

  4. The feed displays perfectly in Opera 7.5 (I am using the newest 7.5 Beta 1, Crash Test Dummy edition (that’s its official name), build 3748.

    In fact, I get a horizontal scrollbar in Firefox 0.8/win, and nothing of the sort in Opera.

    I wish the Norsemen added support for Atom, for M2’s instantly searchable mail database model is also applicable to newsfeeds. As of now, we are reduced to using our browser to view Atom feeds, so CSS-styled atom feeds are always welcome.

    I have had a styled Atom feed for a long time, and it is really a nice thing to do for users. One can even use a favicon, so that people who use Atom in panels, have a nice icon instead of generic bookmark icon.

    Which Opera version did you use, given your claims about its not rendering the feed correctly?

    M.

    — Moose #

  5. First, I thought that the content-type for Atom feeds was ‘application/atom+xml’? Or did you “disable” that because of a bug In Mozilla (http://bugzilla.mozilla.org/show_bug.cgi?id=155730 )?

    Second, using XSLT works quite well. My personal example is gone when I switched software, though Dave Shea still has one (http://www.mezzoblue.com/rss/2.0/ ). Note that IE goes into quirks mode iirc, but does support it. I think that Atom will be the same if you move the inserted (X)HTML to the XSLT file itself.

    — Anne #

  6. In the display in Firefox, there are no links to the underlying blog entries. This seems a shame.

    — julian.bond #

  7. Looking good. I’ve been playing with styling of non-display XML too, I hit a wall with CSS [1] but with XSLT [2] anything is possible – even working with IE!

    [1] http://semtext.org/pets/sambuca-css.xml
    [2] http://semtext.org/pets/profile.xml

    [my first TypeKey post! miaow!]

    — danja #

  8. Wow that is a nice idea bringing in new inline XHTML to style, pitty the links currently don’t work in Firefox (0.8), and of course (as expected), doesn’t work at all in Safari.

    I think using XSL is the next step Mark, if I wasn’t busy revising, I’d get to work on my feeds.

    — Neil Dunn #

  9. Moose: I was using Opera 7.23. Time to upgrade! You’re right, it’s flawless now. I’ll update the post. Yay Opera.

    — Mark #

  10. I notice that in the blurb, you don’t have a recommendation for Linux. Do you have any opinions on the better feed readers on *nix/X?

    — Michael Leuchtenburg #

  11. Bloglines works well under Linux. Also Straw.

    http://www.nongnu.org/straw/

    — Mark #

  12. Damn, this comment system is buggy as hell. Just got “There was an error with your comment submission: registration is required. Thanks for signing in, Mark. Now you can comment.”

    — Mark #

  13. TypeKey? You Blow Me.

    Mark have you noticed your search results are currently a mess? I’m guessing thanks to Movable Type 3.0.

    — Neil Dunn #

  14. “Every time you use TypeKey, God kills a kitten.”

    Well, I don’t like cats much anyway.

    Like everybody else, I’m getting a horizonal scrollbar in Firefox, but that doesn’t bother me as much as the translucent scroll image being quite a distance to the left of the mouse when I middle click.

    Of course, middle clicking on raw XML causes all of the document’s default styling to be dropped, leaving a huge wad of text, so I guess it’s an improvement.

    — Josh #

  15. Mark, I’m the idiot who just visited your page with FireFox, MSIE then wget …

    … the latter raises a question that sorta answers itself but I’ll ask just because I’m an old poop and need some finality on such things.

    Okay, once I completely render my page as XML via XSLT, will I be required to provide any form of autodiscovery?

    And once your efforts will result in a MT template that I and others will gladly implement the next time I upgrade MovableTYpe, will there be any sort of push to encourage aggregator developers to recognize “the page is the feed?”

    — MeanDean #

  16. “I’m surprised no one has pointed out the irony of my using inline XHTML at all, given my strong and well-publicized opinion of XHTML for general use. In fact my HTML is virtually XHTML anyway, except for unclosed |img| tags.”

    Why do you (incorrectly?) close some |input| tags in the XML style ( /> ) while others don’t have the closing tag, as required?

    — lambal #

  17. The entire comment form is generated by a single MT 3 template tag, MTCommentFields, which generates invalid markup. It’s a known problem which I haven’t bothered to hack around yet since the betas are flying fast and furious and I’m lazily hoping that they’ll fix it before anyone notices. Oops, too late. Well, now I’m hoping they’ll fix it before anyone else notices.

    Generating invalid markup is an unacceptable bug in a web publishing tool. It’s the sort of thing I have migrated away from other tools because of.

    — Mark #

Respond privately

I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)



§

firehose ‧ code ‧ planet

© 2001–9 Mark Pilgrim