application/xhtml+xml? Take care

Update/change: I originally wanted to serve these pages with application/xhtml+xml as it’s MIME type. At one moment, you might want to do this, too. There are a number of things you should know.
I tried (I’ll tell you how), and I ran into so much trouble I eventually went back to serving tagsoup text/html.


Serving your nice, fresh xhtml pages as application/xhtml+xml has it’s advantages, as a conforming user agent should refuse to render your pages if your markup is invalid. If text/html is used, a browser should revert to tagsoup-mode.
I like the idea that invalid documents shouldn’t render. If a document has errors, I’ll discover it today, and spend two minutes correcting it. Which is way better than having to correct thousands of documents in a couple of years, when Mozilla 11.0 and MSIE 12.5 is released, having thrown away all of their tagsoup-legacy.
However, there are a number of obstacles when you want to do the right thing. The first one is Internet Explorer. MSIE doesn’t recognize application/xhtml+xml, and prompts you with a download dialog instead of trying to render your page.
Well, I mentioned MSIE, but there surely are other browsers out there that might have a minimal understanding of XHTML, but still expects it to be served as text/html. This can partly be solved with some mod_rewrite magic I found over at Pete’s Guide. It sets the Content-type header to application/xhtml+xml for those browsers that undertands it.
This mod_rewrite magic is also what started my eight-hour nightmare (Update: eighteen-hour nightmare). By writing this, I hope to relieve you of yours.
Opera 7, beta 2 is well capable of handling xhtml documents as XML. Problem is it doesn’t send application/xhtml+xml in the http-accept header. This is bad ju-ju for the mod_rewrite trick, as it then will send Opera into text/html-tagsoup mode. I could of course have added to the mod_rewrite directive, so any User-Agent string that contained “Opera” was served the correct MIME type, or I could have renamed every file to use .xhtml as it’s suffix, but I fear that might have thrown off other browsers and older versions of Opera.
So, just to se how Opera 7 handled my documents, I created some static copies pages on this site, and gave them xhtml as suffix, to see how Opera handled them.
According to the appendixes of XHTML 1.0, a document that lacks an XML declaration, and where no charset information is being sent with the http Content-Type-header, should be treated as utf-8 or utf-16. Which I presume Opera does.
However, an old way of specifying charset information is through the <meta> element, like this: <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" />. I had this left over in my templates (It’s actually still there, if you care to examine the source).
By accident, I had forgotten to send any sort of charset information with either http headers, or through the XML declaration. Guess what? Opera crashed. Just because the meta element suggested a different charset than an acceptable one.
Yeah, I know. Bug. Still, it means that I won’t be sending Opera into anything but tagsoup-mode until this is fixed, and the O7 betas are pretty much eradicated from my logs.
Update/Addition: Then came Mozilla. When I discovered that some of my pages looked radically different, having white borders added to the top and bottom of the document, plus all of the documents in the blog had their background-color changed to something vaguely resembling white, I thought: enough is enough. The mod_rewrite is gone. Your browser is eating tagsoup. I’m happy, I’ll rather validate with a cron-job. At least until the browsers get their act together.

3 Comments

  1. Note that Mozilla’s behaviour is actually not a bug. In XHTML you have to set the background on the <html> element, not the <body> element. This is because the HTML working group told the CSS working group that they didn’t want XHTML to be treated in any way specially (CSS has a number of HTML-specific rules, like applying rules to the canvas).
    E-mail me if you want more details.

  2. application/xhtml+xml—Take care?

    Following up on yesterday’s entry, Virtuelvis has pointed me to his year-old experiences with serving in application/xhtml+xml. That article comes with dire warnings against doing it, in light of a few big bugs and gotchas. But that was then, and…

  3. Serving XHTML Properly

    Recently, I read an article about how you should serve your XHTML pages. I ended up learning quite a bit from that article, mainly because, although…