XSLT

Discovering the cool Symphony CMS has gotten me thinking about XSLT. Symphony uses XSLT more or less as a templating language. I’d already seen XML-based templating languages like Genshi, and avoided them because I couldn’t see the advantage of using verbose XML syntax for templating. XSLT as used in Symphony is a bit more appealing because it goes directly on top of the XML data, using XPath selector expressions to pick out the right content. Storing data in XML and then transforming it into HTML with XSLT is a pretty elegant way of doing things: we all love writing HTML without any presentation information and then using CSS selectors to style certain parts — why not bring the same paradigm a step lower, using XPath to select elements of raw XML data and then insert the selected data into an HTML template with XSLT?

But XSLT really gets interesting when you consider that it can be executed client-side. XSLT has been around for a while, and the major browsers support it. All you have to do is put a <?xml-stylesheet href="mystylesheet.xsl" type="text/xsl"> in the top of your XML document as if you’re putting a CSS link in the top of your HTML document. When the browser opens the XML document it will load the referenced XSL template, process it, and render the resultant HTML, just like browsers today load and apply CSS stylesheets referenced at the tops of HTML documents (which might happen once your XSL produces HTML). Moving templating client-side means that XSL templates can be cached in addition to CSS stylesheets and JavaScript files, so that after the first request, the only thing that goes across the wire is the raw XML data — much more efficient than sending the same header, footer, and sidebar every time.

Also, the server could use the User-Agent HTTP header to dynamically change the stylesheet declaration in the XML document based on what browser is requesting it — one template could be sent to normal browsers, another, simpler one to mobile browsers, even another to aural or braille browsers, etc.

I’m intrigued. Maybe in a few years, those rails apps that serve XML if you tack “.xml” onto the end of the URL will serve only XML, and all templating will be done client-side.

Site-Specific Browsers

Seeing SSB’s like Fluid, Mozilla Prism, and Chrome’s shortcut feature have made me wonder, what’s the big deal about a browser with no controls that can only go to one site? Why would you use this instead of just opening sites in a full-fledged browser like always?

By giving a web application its own window and an icon on the desktop/dock, it moves web apps out of the browser into the domain of the operating system: you use the OS’s desktop or dock to launch them instead of your browser’s address bar, you can use exposé on them on a mac, you use your OS’s window-cycling keyboard shortcut instead of your browser’s tab-cycling keyboard shortcut to cycle through them, etc. Fluid goes further towards integrating web apps into the desktop by exposing some Cocoa APIs like setting the dock badge and sending Growl notifications to JavaScript. Anyway, By using the OS’s interface to manage web apps instead of the browser’s, it makes web apps seem more legitimate. That’s it, really. The hype on the Prism blog post is a bit much.