Journal

XHTML 1.0 Rollback

29 November 2005 › 14 comments

Rolling back, Wal-Mart style

Lately I’ve been thinking about the implications of declaring document types, and various methods of encoding when serving hypertext. After wrestling with this question, getting advice from web-gurus like Roger and Bryan, and doing a little of my own research, I decided to do the moon walk. I have rolled this site back to XHTML 1.0 Strict, instead of XHTML 1.1. My decision was finally swayed by the specs on the W3C XHTML Media Types page:

http://w3.org/TR/xhtml-media-types/#summary

In case you are short on time or just lazy like I tend to be, I will save you having to read that entire spec, and just cut to the chase. My decision to go back to XHTML 1.0 Strict is due to it being the strictest flavor of XHTML that is allowed to be served as text/html as opposed to application/xhtml+xml. Below is a screenshot of the XHTML recommendations chart (click to enlarge).

Now, I am sure someone will point out that it does indeed say “Should Not” under XHTML 1.1, meaning that it is technically still possible to serve it as text/html, without the sky falling. That is all well and good, but I tend to be a visual person, and that scary red color under HTML which reads “Must Not” is the same shade as the “Should Not” under XHTML 1.1. Suffice it to say that the W3C does not want us to go about doing that.

Darn blue “E”

So, you might be wondering, “What’s the big deal? Why not just stick to XHTML 1.1 and serve it as xhtml+xml?” Good question. The reason is Internet Explorer, gem of a browser that it is, does not yet support this content-type. What I am referring to of course is the Windows version, as the Mac IE5.2 has long since been retired.

Astute reader that you are, no doubt you are thinking “Internet Explorer 7 is right around the corner, surely this will be fixed!” Well, sorry to burst your bubble, but no – this will not be the case. It was announced in September on the IEBlog that IE7 will not feature any newly added support…

IE7 will not add support for this MIME type – we will, of course, continue to read XHTML when served as “text/html”, presuming it follows the HTML compatibility recommendations. We fixed the problem with our DOCTYPE switch explicitly so that this mechanism is easier to use, and it is generally easy to set up most servers to conditionally serve content as “text/html” when the “application/xml+xhtml” MIME type is not supported. – IEBlog

Basically that means if you want to serve XHTML as application/xhtml+xml to modern browsers, but not leave IE6+7 users out in the cold, you need to do some server-side trickery in order to serve up text/html to Internet Explorer. While this is a perfectly legitimate solution, I have never been a big fan of code-forking, which is what this seems to resemble.

So, I had a choice to make. I could have gone all-out and done some hardcore content-type switching like Jeremy Keith. If you go to his site in Firefox, you will notice that the content type is application/xhtml+xml but if you view it in Internet Explorer, it is text/html. For sure that is really cool, but a bit more than I wanted to do, especially worrying about having to set that up for client sites on various servers. The other extreme would be rolling back all the way to trusty and reliable HTML 4.01 Strict like Roger Johansson.

Fork in the road

So, I decided to fall somewhere in the middle, and go with XHTML 1.0 Strict but serve it as text/html. My reasoning for this is 1.0 Strict and 1.1 are close cousins. In fact, to remedy my little dilemma, all I had to do was change a few lines in my code and everything validates as 1.0 Strict again. If you’re curious as to the differences, read: Changes from XHTML 1.0 Strict. Plus, I feel justified since Doug Bowman uses 1.0 Strict with text/html.

I didn’t want to go back to HTML for several reasons: One, I don’t trust my own coding consistency, and like the rigidity of XHTML validation. Two, I like XHTML 1.0 Strict vs. Transitional, because it forces me to rely a little more on CSS for presentation, rather than HTML attributes like align="right". Three, Textpattern outputs XHTML by default, so using it for HTML would be tedious.

Now, don’t get me wrong. I am not saying that one method is inherantly better than another. What does matter is that you are writing clean, valid code for whatever document type you choose. Also, you should take into consideration the majority browser market share. Unfortunately, that means continuing to cater to Internet Explorer until it catches up with other browsers, or drops off entirely, whichever comes first.

Summary

So, what have we learned? Not a whole lot, other than a bunch of techno jargon. If you take anything from this article, let it be this: Produce good, semantic markup no matter what doctype you choose, and keep your code consistent to that type. Also, if you are using Dreamweaver 8, and choose XHTML 1.1 from the New menu, make sure to interchange these lines:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />

That is of course, assuming that you are actually going to serve XHTML 1.1 the way it is intended, and will make the appropriate server-side changes for content-type negotiation to enable IE users to still view the page correctly. If not, then you might as well choose another doctype, and serve text/html.

Discussion + Dissension

#1 Yannick

Thanks Nathan. This was a helpful and informative article.
#2 Ray

Thanks for that XHTML recommendations chart! Before now I never really knew about that chart. Is that the ultimate in stupidity? Not knowing that you don’t know? I’ve saved that chart for reference later. Oh, and I love your warning at the top for Internet Explorer users. I just noticed it today. Priceless. :)
#3 Ara Pehlivanian

Hey Nathan,

Nice article. I can totally relate. I recently had my own XHTML dilemma and it was sparked in part by your post on XHTML in laymans terms and a whole spate of articles by Anne. Suffice it to say, I went the route of application/xhtml+xml after much agony over the issue.

I do salute your decision to use XHTML 1.0 with text/html as it is allowed as per the spec (I didn’t know this originally but Molly cleared that up for me ;)

As far as code forking goes, I found a great little plugin for WordPress that just checks the user agen’ts Accept: setting and feeds it either text/html or application/xhtml+xml. My pages get sent just fine because of it.

One caveat with going full on application/xhtml+xml though. The browser invokes its XML parser and it’s 100% unforgiving. If your markup is even malformed in the slightest way (just one unescaped ampersand, or one unclosed tag) and the page stops parsing and you get a big fat error message. :-)

God Bless
#4 Nathan Smith

Yannick, Ray: Glad the article was informative. While I’m no expert, I just figure I should document my own coding blunders and experiences, so that others can avoid the same hang-ups. I wouldn’t sweat not knowing about the chart Ray, I just discovered it recently.

Ara: That’s good to know about the WordPress plugin. Matthew Mullenweg (WordPress founder) should make use of it. On his own site PhotoMatt.net, he’s using XHTML 1.1 but serving it as text/html, a big no-no.
#5 Nathan Logan

I’ve always been a bit confused by this whole discussion.

Why is using XHTML 1.1 and serving it as text/html a big no-no? What are the practical negative implications of doing so?

And the phrase “kissing cousins” should be banned from your vocabulary. Forever. ;)
#6 Ara Pehlivanian

Nathan: From my understanding, the reason why XHTML 1.1 is no good under text/html is due to the fact that it’s modular and so requires different treatment. Because, even though the current parser recognizes all of the elements that are standard HTML, what will it do when it encounters an instruction that resides in a different module that isn’t available?

The deal with all of this MIME type switching really just boils down to what parser you invoke in the browser. Unfortunately, browser makers muddle the issue quite a bit by doing things like compensating for errors.
#7 Nathan Smith

I second what Ara said, but wanted to add that XHTML 1.1 is meant to be compatible with other XML formats, so that it can be coupled seamlessly. These other formats, such as MathML do not have text/html equivalents, and so must be served as application/xhtml+xml to be compatible with XHTML.

Nate: Duely noted. I changed it to read "close cousins" - now it doesn't sound quite so silly. I didn't mean to make such slanderous implications. Very sorry XHTML 1.0 and 1.1, I meant no offense!
#8 jason carlin

Inevitably half of the conversations I have in life end up with one final thought. Someone ends it all with a phrase like: “The point is mute. IE doesn’t support it and that’s by far the majority of our userbase.”

Sometimes that bitter truth goes down easier than others. This time, it’s a no-brainer. Not only does IE not support serving pages as application/xhtml+xml, but we already know the upcoming version won’t either. AND the benefits of serving application/xhtml+xml are… well… what are they again?

Increased server-side complexity + diminishing returns
= something someone would only do so they can say they did it
#9 Nathan Smith

Jason: That is pretty much my opinion too. I knew that the differences between XHTML 1.0 Strict and 1.1 are minimal, but I made my site XHTML 1.1 for awhile just to “show off.” Practically and realistically though, there’s no good reason why my site would have to be served as 1.1, as I’m not doing any cool MathML interaction. So, back to the tried and true text/html.
#10 Mike Montgomery

Thanks for the article.

I agree with your points and would do the same, if I could sort out exactly what to do. (Answered my own question—see below)

As I understand it, you’re basically talking about the first two lines of the code. (Not fully correct)

From a view|source of this page, I recognized the 1.0 strict, but I don’t recognize text/html anywhere. (Then I saw the fourth line, and there it is.)
#11 Nathan Smith

Mike: Um, cool – glad I could be of help, and get those questions answered so promptly for you! Let me know if you need anything else. ;P
#12 Henrik

Why don’t u just add the lines yourself? It’s approximately 4 lines of PHP or ASP.Net that is required to make it happen. It’s very easy. Want some links?
#13 Nathan Smith

Henrik: Sure, I wouldn’t mind a few links. I just didn’t see the reason to use 1.1, as I’m not making use of any of the extra features it provides.
#14 Henrik

Alright, well, you could start writing maths on the web, or using SVG…

.NET:

if (Request.ServerVariables[“HTTP_ACCEPT”].IndexOf(“application/xhtml+xml” != -1) {
Response.ContentType = “application/xhtml+xml”;
//and write the xml declaration
Response.Write(“”);
}
else{
Response.ContentType = “text/html”;
}

http://www.aspnetresources.com/blog/aspnet_xhtml_content_types.aspx

PHP - Just put this on top:

< ?php
if ( stristr($_SERVER[“HTTP_ACCEPT”],”application/xhtml+xml”) ) {
header(“Content-type: application/xhtml+xml”);
}
else {
header(“Content-type: text/html”);
}
? >

http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html

Comments closed after 2 weeks.