Carl Camera

In Search of a de Facto Standard

Updated 2 Nov 2005: XML namespace attribute added [see note 1]

Amid seas churning with DOCTYPE indecision and littered with the flotsom of MIME-type argument wreckage, I've decided to harbor in the relative safety of XHTML 1.1 and text/html. That is, until I see a clear de facto standard trend -- or someone (perhaps you) convinces me otherwise, I'm staying put.

Hurricane "DOCTYPE"

John Oxton recently started a conversation asking if XHTML and CSS are easy. It is a deceptively profound question because they are easy but there are few best-of-breed designers embracing them. Or rather, it. XHTML. I think everyone is agreed on CSS, it's the XHTML portion of the pair that generates debate.

XHTML is easy to understand - I can teach well-formedness to just about anyone in five minutes. Easy stuff. So let's take an unscientific survey of the design landscape by reviewing the DOCTYPEs of several top designer sites and their validity results [see note 2].

  1. If XHTML is so easy, then why are these folks serving HTML4?
  2. Why can't these folks get their XHTML to validate?
  3. But these folks can?

Why are some people using Transitional and others Strict? Aren't they all targeting the same audience?

If the internet design lords can't agree on the proper content markup course, then what are we, the internet design cerfs supposed to do? I wish these folks would provide some leadership in this area.

In Defense of XHTML 1.1

I'm sticking with XHTML 1.1 because it is, last time I checked, the W3C recommendation. And yes, I will serve it up unashamedly as text/html. This isn't the first time I've made a standards compromise to ensure browser compatability.

Please understand that I, in no way, believe my tag soup is better than your tag soup. I'm just trying to find somewhere to moor my DOCTYPE (to really belabor the analogy) until the design waters calm. XHTML 1.1 seems as good as any other.

What is obvious, however, is that 100% pure compatibility will have to wait.

Note 1:

Sincere thanks to Anne van Kesteren for sheding some light on how browsers deal with MIME and DOCTYPE declarations. is referenced in the article and, indeed, at the time of Anne's post, did not contain an XML namespace attribute in its DOCTYPE declaration. It does now.

Note 2:

HTML validity checks were made on 31 Oct 2005. I did not perform any sort of site-wide exhaustive search looking for validity errors, I just poked around for a few minutes to see if I could find any. If I didn't find any, then I moved on.


Are you sure doing stuff that the w3c says you should not do is a sensible basis for your choices here?

In order to serve XHTML reliably as text/html you have to follow the HTML compatibility guidelines, which means you need to use a subset of XHTML, which isn't tested by checking for well-formedness.

On the other hand it's perfectly possible to write very clean HTML4.01 (again using a subset of the published standard), the advantage is you can serve it as text/html and be within the w3c's recommendations.

Sounds to me like you have no real reason to want to use XHTML1.1 over XHTML1.0, or HTML4.01, other than it's got an 'X' in it, and 1.1 is bigger than 1.0.

Offer some real positive reasons for using it.

Dan 02 Nov 2005

Dan, the geek in me definitely wants to be at the standards forefront, but there's more to it than that.

In looking to the future, there is no doubt in my mind that XML will be the basis of internet browser interactions. The sooner I get on board, so to speak, the better. Furthermore, I'm taking a pragmatic view of dealing with the browser landscape over the next five years.

IE6 is the reason people use to justify avoiding XHTML 1.1. "If I can't serve it with application/xhtml+xml", they say, "then I'll just serve up some previous standard."

Their rationale is complete W3C compliance, but I fear they might be hurting XHTML adoption as a result. If we all take this stance, then we won't even begin to see widespread adoption of XHTML 1.1 until about 2010. Here's why:

Flipping the switch to the recommended XHTML 1.1 MIME type doesn't degrade well, now does it? For all intents and purposes, it breaks IE6. Even if IE6 is one-half of one percent of the browser market, serving up XHTML 1.1 with application/xhtml+xml will erase your site from tens of thousands of users. For those taking the stance above: what percentage of the browser community are you willing to ignore, and most likely annoy?

I simply will not wait for IE6 to fade from existence before moving forward with my DOCTYPE. The XHTML 1.1 standard allows for serving it up text/html, so I'm in compliance.

More than likley, everyone will be client-sniffing and serving up XHTML in different formats in the near future. I'm certainly investigating dynamic MIME type solutions. Then, if we're all dynamically serving up XHTML with different MIME types based on browser capabilities, what reason is there to lag behind?

Carl Camera 02 Nov 2005

Looks as if IE7 won't support application/xhtml+xml either:

2010 may be a good bet...

Tim Groves 10 Nov 2005


Exactly. The problem doesn't go away when IE8 (assuming it will handle xhml+xml MIME) appears. The problem goes away when IE7 disappears.

Carl Camera 10 Nov 2005