Useful doctype/rendering mode thingie

[blufive]

Henri Sivonen has assembled a most excellent guide to what rendering mode you'll get in the leading browsers for any given doctype.

[edited 21/12/2007, to fix linkrot]

Comments

[kingandy]

Hmm. So IE6 will never quite match those standards.

I suspect the width style is one of the things it won't compromise on...

[fridgemagnet.livejournal.com]

Reading through (and unsurprised that IE never renders as standards-compliant) I noticed the last section about recommended doctypes, which says

I am not recommending any of the XHTML doctypes, because serving XHTML as text/html is considered harmful.

Right. Why's that? It links to an article (http://hixie.ch/advocacy/xhtml) saying

If you use XHTML, you should deliver it with the application/xhtml+xml
MIME type. If you do not do so, you should use HTML4 instead of XHTML.
The alternative, using XHTML but delivering it as text/html, causes
numerous problems that are outlined below.

Unfortunately, IE6 does not support application/xhtml+xml (in fact, it
does not support XHTML at all).

Oh well. That's really useful, isn't it? Basically you can't use XHTML according to these guys.

I think I might ignore that.

[blufive.livejournal.com]

I am familiar with both Henri Sivonen and Ian "Hixie" Hickson from other sources. Hixie, amongst other things, works for Opera (the browser people) and is the editor of a couple of CSS3 modules. HS just seems to really his stuff.

Let's just say they are both from the standards-all-the-way crowd. I respect them both - they often have very interesting things to say (which I will usually listen to and consider carefully) but sometimes, I have to disagree with them.

This is one of those times.

The dilemma with XHTML is: there are two ways to deal with it from a programmatic point of view. You can pretend it's just a slightly more rigorous version of HTML, or you can give it the full-on XML treatment.

As I see it, both approaches have their advantages. (HTML: you can just tweak your existing HTML engine to cope with it, XML: you can use well-tested off-the-shelf XML parsers and tools - don't knock it until you've seen what XPATH, XSLT and their friends can do).

At a few points in my day job, I do the full XML-thang. Very useful it is too, and I plan to expand this approach into other areas, where I reckon it can save us a metric shedload of grief in the long run.

Mozilla and Opera swing both ways, controlled by the mime-type.

IE6 is steadfastly rooted in HTML-land (as demonstrated by the fact that it barfs on the required-by-XML encoding-preamble) So, on the web using the full-on XML approach is a non-starter.

HS and Hixie are of the opinion that, if one wishes to do something, one should do it PROPERLY. Which is to say: XML-mode.

In this situation, I reckon I'll just continue treating XHTML as HTML (when it's on the web) and XML (when it suits me to). After all, if browser support improves, I can punt those web pages over into XML mode by a few minor mime-type tweaks on the server, without rewriting any content. Hell, if I'm fealing really brave, I can do a browser-sniff and adjust the mime type accordingly.

[blufive.livejournal.com]

HS just seems to really his stuff.

Oops. KNOW. Really KNOW his stuff.

[fridgemagnet.livejournal.com]

Well, quite. If the options are (a) writing everything as HTML 4.01 and then, at some future date when things are lovely, converting to XHTML or (b) publishing XHTML, knowing that browsers are going to read it for the foreseeable future and, once XML support improves and it's relevant, being able to tweak a little and be fine... I know what I'm going to pick.

I'm happy enough with writing in XHTML purely on a local basis, so I can use all sorts of nice Perl tools with my code. Not that I do very often, but the option's there.