As explained in one of the first posts on this blog this site is basically just one big Atom feed that gets transformed into this blog by using a bit of Apache content negotiation and client side XSLT. Besides some issues with browsers ignoring client side XSLT in a feed and forcing their own rendition of my feed which was fixed by inserting 512 bytes of crud to throw of the feed sniffing this approach has worked fine for the last four years.

Alas these happy years are now over due too Internet Explorer 8. For reasons unknown (and undocumented) IE8 no longer respects the 512 bytes of crud workaround and insists on deploying its “friendly” feed view on everything it perceives as being a feed, client side XSLT and 512 bytes workaround be damned.

Given the potential audience for IE8 I can’t go on with my favoured method and I have decided to switch to a server side XSLT rendering. Given the high level of standardisation available within XSLT I didn’t have to change a single item in my stylesheet.

Whilst on the experimental track I took some time to play around with typeface.js and Cufón. I had already used SIFR on this site and I was interested in how it would compare against these newcomers. Both typeface.js and Cufón are completely javascript based solutions that embed their fonts as javascript files in the page. Getting both libraries to work required a bit of tinkering to acquire a feel for their approach but basically all examples and code where up and running in minutes. There’s not much difference in how both libraries work, they both use javascript with a combination of <canvas> or VML elements. From an aesthetic viewpoint I like Cufón better because the fonts seem crisper than those of typeface.js. This might have something to do with the extensive font rendering process that was created for Cufón. I set the <h1> and <h2> in Cufón and I like the results enough to abandon SIFR. I even tried to set an entire page in Cufón but that to all kinds of amazing behaviour within FireFox (even crashing it) so I decided to let that approach rest. It did however get me started on looking in/back to CSS 3 font-face adoption which seems to be imminent for the large browsers with Safari 3.1 already implementing it. For those of you that use Safari 3.1 (or are using a browser that supports font-face now) I have set the paragraphs in Delicious Roman, a free font from Jos Buivenga.

Oh by the way the server side XSLT rendering is done with PHP. All requests for XML files are forwarded by Apache based on a specific AddHandler and Action.

# Handler atom_xslt is associated with xml files
AddHandler atom_xslt xml

# Subsequently handler atom_xslt is associated with index.php
# for actual processing
Action atom_xslt /index.php 

# Force everything to the feed
DirectoryIndex index.xml

A simple caching mechanism is applied by the PHP script to render to HTML once and only update the rendered file after either the XML feed or the XSLT stylesheet have been update. Now that I don’t apply a client side XSLT anymore there’s no reason to stick with XHTML anymore and I have switched to HTML 4.01 Strict.

No related posts.