Have a look at http://feedme.mind-it.info/, it uses client side XSLT to transform an Atom feed into XHTML 1.1 for application/xhtml+xml compliant browsers (the rest gets XHTML 1.0 Strict). It uses some nifty real world Apache trickery to get things really working. All details are explained in the blog posting. The purpose here is to make the feed the website and vice versa because if you have a feed you have all the content you need :-)

Regarding feed behaviour of browsers not respecting the XSLT and delivering it straight to the browser as a feed there’s a workaround that I applied on my feedsite. Check the source code and you’ll find out how :-)

It’s a shame you can’t see custom-designed feeds in Safari, Internet Explorer 7 nor Firefox 2. All this good work is going unnoticed.

..but how do i manage to insert the tag when i’m loading an external xml (such your flicker or, in my case, a bloglines rss)?

> The expression / matches any element

That’s not true. The expression / matches the document root, and nothing else. And by document root, I don’t mean the document element (atom:feed) but the actual root, the document itself. This is an explicit example in XSLT 1.0 Section 5.2 “Patterns”.

@trovster: at first I thought so, too. But at least in Safari you can turn off the RSS support (via the Debug menu) and look at the nice formatted feeds.

For client-side transformations I sometimes used the javascript Freja framework, that allows to work with more than one XSL file in the same time.

saski:

You don’t have to insert a “tag” (processing instruction). When your browser comes across the processing instruction it starts up an instance of its XSLT-Processor and passes in both the stylesheet and your XML-Document.
That is exactly what you have to do. The question is, which language do you use??

Check out http://php.net/xsl – it should demonstrate the concept.

I totally fell into XSL by using a Publishing tool called Symphony. The fact that the interface looked cool, the language was something that was recommended by the W3C and also it further separated chunks of code that could be reused in different scenarios totally appealed to me.

Sebastian is correct about / matching the root of the document. XPath is based on UNIX path semantics so it should be pretty obvious.

Personally, I don’t like splitting up my code into so many templates. It’s old school xslt imho and makes the markup difficult to follow. Use xsl:for-each instead. Calling templates by name and using param’s is incredibly useful for creating xslt’s equivalent of functions. You could, for example, create a css constant processor for Rachel’s article this way although it’d probably have to be done server side.

Hmmm. Worth looking into…

Kevin, interesting take – but I tend to stand on the other side of that particular fence. For me, template matching is the most beautiful concept in XSLT. It’s the default behaviour by design, I can never understand why anyone would want to tamper with it by littering their stylesheet with < xsl:for-each > and called templates when there’s no good reason to do so, although I see it all the time. There’s nothing more elegant to me than being able to match the root node, apply templates and just pick out what you need by matching, not that it’s ever that simple in the real world alas.

XSLT is immensely powerful, but if I found myself regularly attempting to replicate traditional programming concepts within it I’d start to question why I wasn’t using a traditional programming language in the first place.

Ian, nice article, it’s a subject that doesn’t come up often enough. I do have one issue though: Within the template matching the category element, the context node is a single instance of a category element. The < xsl:for-each select=”.” > is therefore redundant as it will only ever match one category element – the current one. This template is already invoked independently for each category since you used < xsl:apply-templates select=“atom:category” > in the entry template, the < xsl:for-each > adds nothing but a slight processing overhead to each pass.

Sorry guys, I’ve been tied up recently and not had a chance to reply.

So in total agreement with Will about Templates. For-each’s will get you so far but if you want to keep things simple, neat and readable I would suggest Templates.

On with Will’s point
See this is the problem with XSL, its a great transformation language in need of a good pipeline framework around it. I’m using Cocoon for lots of my serious XSL building and it makes things so much quicker and I don’t ever have to worry about replicating programming concepts. Also XSL 2.0 now has things like regex and the ability to do many to many transformations without a pipeline framework like Cocoon. Yes you need Saxon 8+ but it comes on Java and .Net now, so there’s no excuse now.

Good point about processor overhead with my for-each, its a old habit of mine.

To the earlier points, I was tempted to put in a part about the difference between Client-side and Server-side transformations. Client-side is useful when you have control over the feed or use javascript but ideally server-side makes more sense for most usage.

+1 for Symphony.

XSL actually works. never again will i touch wordpress/textpattern!

@trovster:

Not really going unnoticed… The purpose of styling your feeds is to avoid that horrid error-like page most browsers show. If they display them nicely and on top of that ask you if you want to subscribe to it, all the better.

I’ve xsl-ed my feeds from day one on my blog for one reason alone. If someone not familiar with feeds click on them, they should be helped finding their way (ie, suggest feed readers, etc), not give them the XML and don’t care if they’re able to use it or not. :)

XSL and XSLT are the inventions of the demons. Worst programming idea ever. XML is a data structure, NOT a bed for procedural code. It’s clumsy, big, and incredibly limited. For those of you required to work with it, I pity you. For those who do so out of choice… you should probably go get your head examined.

You are indeed a beautiful person: worked 1st time right out of the box.