If your browser supports it, this site's pages will be served to you as application/xhtml+xml. What on earth does that mean? It means it's standards compliant, for one thing. But standards compliance is pretty pointless if the standards weren't designed with good reason. Let's explore the issue a little.
A while ago, I wrote about why serving XHTML (the language with which this site happens to be marked up*) as application/xhtml+xml is cool. There's more to the story than that, though. For more of the same (why it's cool), but with much more detailed arguments, read this piece by Ian Hickson.
There are, however, downsides to serving XHTML as application/xhtml+xml. The greatest of these, by far, is that malformed XHTML in the page can cause a fatal error. In other words, if I make a typo when I'm coding one of these pages, your browser may not let you see the page at all. Arguably, that keeps me on my toes and ensures I'm writing well-formed XHTML. Unfortunately, this is also an issue that affects user-generated content. In the context of this site, the only user generated content is in the form of comments (if you didn't know, you can comment on the article below; try it out!), but still, this would mean that if a user entered - by mistake or on purpose, it doesn't matter as far as the computer is concerned - ill-formed XHTML code into a comment, that could prevent you or anyone else with a compliant browser, from viewing the page at all. That's not cool; it's basically providing all you nice readers with a way to mount a denial-of-service attack against pages on my site!
So how can we get around this? Various ways. The main one is to ensure that ill-formed XHTML doesn't get served, even if it's what was entered. On this site, I've done that for the comments by setting up a plugin that assumes all comments are being entered in a lightweight, popular markup language called Markdown. The Markdown plugin, in theory at least, won't generate ill-formed XHTML, even if the user has entered some; the plugin will escape
the ill-formed parts. This will mean that if a user writes a comment that contains ill-formed XHTML, the comment might end up looking a little bit weird in that some of the markup will remain visible (well, with ill-formed code, it's not unreasonable that it should look weird!), but it won't stop the page from rendering.
Have I covered my back on this front? I hope so!
* Specifically, a flavour of XHTML known as XHTML+RDFa.
At some stage, I hope to have time to investigate the ease (or not) with which people can include MathML and other XML languages in comments. I might have to follow Jacques Distler’s approach and offer a choice of comment parsers, but I hope this won’t be needed.
Hmm, interestingly the Markdown Extra plugin doesn’t seem to be working here quite the same way it did on my test site. Odd. Will have to look into this.