What is a Doctype?
“Doctype” is short for “document type declaration”: it declares what type (or “flavour”) of (X)HMTL you are writing. Different types of (X)HTML have different syntax rules, much as different languages or dialects have different vocabularies or grammars.
(By the way, (X)HTML is shorthand for “either XHTML or HTML”.)
Using a Doctype tells browsers how they should interpret your code. This means your website will be rendered with better consistency, because browsers don’t have to guess which set of rules to apply. If you make them guess, then they will sometimes guess wrong.
The Doctype belongs at the start of your source code, before the html tag. For example, here’s a simple web page:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>My first valid web page</title>
</head>
<body>
<p>Hello world!</p>
</body>
</html>
If you just want my recommendation, use the Doctype given above: HTML 4.01 Strict. In my view, this the best choice for almost any website.
Incorrect Doctypes
Many web pages suffer from incorrect Doctypes. This is usually because the author has copied the Doctype from another website, or because he is using an old design program that inserts incorrect Doctypes. For example, this is an incorrect Doctype (it’s incomplete):
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
Using an incorrect Doctype has two bad consequences:
- Your code won’t validate.
- It will make many browsers switch to an old, buggy rendering method called quirks mode. You really don’t want this to happen: you want them to use standards compliant mode. You can think of incorrect Doctypes as triggering a schizophrenic response in browsers: it’s as though the kindly old lady living next door suddenly becomes a rampaging axe murderess.
Correct Doctypes
I hope you’re convinced of the need for a correct Doctype (if not, you will be when the old lady gets you). So what correct Doctypes can you use?
The W3C has defined a bewildering variety of Doctypes, including some pretty exotic ones (read: almost certainly useless to you). As well as Doctypes for racy standards such as SVG and MathML, you could use an old flavour of HTML, such as HTML 2.0. For most authors, however, these would be absurd choices. Your real options are the following:
HMTL 4.01 Transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
HTML 4.01 Frameset:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
HTML 4.01 Strict:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
XHTML 1.0 Transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
XHTML 1.0 Frameset:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.0 Strict:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.1:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
You may also have heard about XHTML 2.0. XHTML 2.0 is a working draft only; the W3C does not recommend its use. Don’t use it.
Choosing a Doctype
For the rest of this article, I’ll explain the differences between the Doctypes, and you’ll find out why I like HTML 4.01 Strict.
In total, you have seven options. This might seem a lot to choose from, but it’s easy if we split them into groups.
The first thing you might notice is that you have a choice between HTML and XHTML. This issue is a bit complicated, since it’s stuffed full of technical complications and confused ideology. Let’s set it aside for now.
The other choice is between Transitional, Frameset, and Strict. This decision is much easier, so we’ll address it first.
Transitional, Frameset, or Strict?
The short answer is: you should use Strict.
Strict is harder for beginners to get right, because you have to write better code. For example, you must remove presentational elements such as tags, and use CSS instead to style the site. If you’re happy doing this, then you can skip the rest of this section: you’ve already made the right decision. If you’re still uncertain, read on.
To understand the differences, we need to go back to the Bad Old Days, in the 1990′s, when web designers were writing horrible, bloated code, hardly anyone had heard about validation, and fewer cared. Browser support for CSS was rubbish, and the web standards movement was in its infancy.
Transitional
Transitional was intended as a stepping stone to help web designers begin to improve their code. The starting point: horrible, invalid code. The end point: horrible, valid code. You can’t expect designers to completely change their coding methods overnight; nor can you expect browser CSS support to go from nearly non-existent to perfect. One step at a time.
Nowadays, browser support for CSS is much better. The only reason for using Transitional is that you’re stuck in old habits and don’t yet have time to learn better ways of coding. If you’re learning web design from scratch, use Strict. Please, oh please use Strict.
Frameset
The Frameset Doctype exists for a similar reason: it’s for those stubborn designers who insist on using frames. Frames are not allowed in the modern flavours of (X)HTML, for the simple reason that they are Very Bad. They are Very Bad for users (can’t bookmark pages properly), Very Bad for search engines (can’t index your site properly), and Very Bad for novice coders (easy to get the code wrong, breaking your site).
Many beginners use frames because frames allow you to keep repeated page elements — such as navigation — in a single file, making it easier to make changes. Frames are the wrong solution to this: instead, use includes. While you might be daunted by the idea of setting up a web server on your computer, it’s not that hard — and you’ll wonder how you ever lived without it.
If you must use frames, then use a Frameset Doctype.
Strict
Still unsure? Use Strict. Deep down, you know it’s the right thing to do.
HTML or XHTML?
Deciding between Strict, Transitional, and Frameset is pretty easy, because only Strict is any good: the other two are cop-outs for designers who are too lazy to learn proper web coding (okay, there are exceptions — but not many).
Deciding between HTML and XHTML is not as straightforward. This is much more of a personal preference, with no clearly wrong answer. But personally, I believe HTML is almost always a better choice. Here’s why:
Many designers see the “X” in XHTML and imagine, perhaps subconsciously, that it stands for seXy or eXtreme. It doesn’t, and basing your web design on the letter “X” is not a smart choice. XHTML might seem modern and edgy (it’s not); you might think it will make you a better coder (it won’t); and you may imagine that browsers will render it more quickly (they won’t). The reality is that XHTML does nothing positive for your website, but can make your life much harder.
To understand the nature of XHTML, we need to put it in context. XHTML was meant to be “the future of the web”. The W3C have two purposes for XHTML:
- They envision it as a stepping-stone to XML, and integrating XML with HTML. In the future, this may mean greatly improved interoperability between all sorts of devices, and other cool stuff such as modular inclusion of other markup languages (MathML is a current example).
- They want to use it to force web designers to write better code. In true XHTML (not the pretend XHTML that everyone uses), any parsing error is fatal.
Neither of these goals has been achieved in the slightest. The genuine adoption of XHTML has been almost totally obstructed by Internet Explorer’s inability to understand it, and almost all XHTML web pages fail to validate (just like almost all HTML pages).
XHTML may be the future of the web, or it may not. So far we’ve seen little progress. The movement for HTML 5, however, is gathering force. HTML 5 is being developed by a different standards body, WhatWG. Here’s how they describe themselves:
In 2004, after a W3C workshop, Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out to with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.
So whatever everyone may tell you, it’s not clear what will be the future language of the web. There are currently two heavyweight standards organisations developing different standards. WhatWG are trying to work with W3C, and ultimately defer to them; nonetheless, the future of the web is not entirely controlled by W3C, but also by browser vendors. It’s a complex relationship.
What is clear, however, is that XHTML makes your life harder. You have to serve it to Internet Explorer with a MIME type of “text/html”, which means that IE treats it as invalid HTML and uses error-correction routines instead of simple standards. You can serve it correctly to other browsers, but you must arrange content negotiation. When Mozilla receives genuine XHTML, it can’t render the page incrementally and so you will see nothing until the entire page has been loaded (this is a bug, and is fixed for Firefox 3).
Also, Google ads won’t work in XHTML without further work-arounds. Sites with user-posted content have trouble too, because a single invalid character in one user’s post can break the entire site. Again, there are workarounds.
Is it really worth all that effort just to practise using a standard that might be useful sometime in the future? Or it might not: HTML 5 might steal XHTML’s thunder.
If you have some practical need for XHTML right now, such as writing MathML, then go for it. But otherwise, it’s a lot of work for little or no reward.
Bad arguments in favour of XHTML
“HTML is yesterday’s language. Modern web designers should use the latest standard, and that’s XHTML.”
HTML is not “yesterday’s language”. Almost all web pages on the Internet, be they old or new, are written in some flavour of HTML, and it enjoys much better browser support than XHTML. There is no reason to believe that browsers will ever drop support for HTML.
And as I said before, there’s little reason to believe XHTML is the future. We have to wait and see.
“XHTML forces designers to use semantic markup”
No it doesn’t. XHTML and HTML are formal grammars; they are syntax, not semantics: nothing more, nothing less.
Syntax and semantics are orthogonal. You can still use tables in XHTML, and you can still do stupid things such as using styled paragraphs instead of real headings.
“XHTML produces cleaner code”
No it doesn’t. HTML 4.01 Strict code can be just as clean.
You want to close all your
tags? Go ahead. No-one’s stopping you from doing that in HTML.
There are only two respects in which XHTML code is “cleaner”:
- Parsing errors are fatal. In other words, a single error completely breaks your site (but only if you’re serving it with the correct MIME type).
- The XHTML validator is correspondingly stricter than the HTML validator, and will force you to use good coding practices such as closing all tags and quoting all attribute values.
But do you really need to be forced? I close my
tags voluntarily, whereas you need the validator to hold a gun to your head. Does that make you a better coder?
Nonetheless, I would love the HTML validator to be as strict as the XHTML one. Guess what? You can make this happen: validate your site against a custom DTD. (And you thought XHTML was hardcore.)
“XHTML may not be useful yet, but learning XHTML 1.0 will prepare me for the future: XHTML 2.0″
First, as I keep saying, you have no way of knowing whether XHTML will be the future of the web. W3C are pushing it, but that means nothing unless browsers support it.
Second, the XHTML 2.0 draft is deliberately not backwards-compatible with XHTML 1.0 or 1.1. If you’re hoping for a smooth transition to XHTML 2.0, you are likely to be disappointed.
“My clients ask for XHTML. They think it’s the new standard. I have to do what they ask”
Would you tell your plumber which kind of wrench to use? Come on, don’t be a pushover. Stand your ground, and explain, in as simple terms as possible, why you don’t work in XHTML.
Try this line: “I don’t work in XHTML because Internet Explorer does not support it. No, really. The XHTML sites you saw were fakes, and I can explain that if you’d like me to.”
If you insist on using XHTML…
Let’s suppose you have (wantonly, stubbornly, callously) ignored my (insightful, benevolent, sagacious) advice, by choosing to use XHTML instead of the lovely HTML 4.01. So be it. That still leaves some choices.
Transitional and Frameset XHTML Doctypes are silly. You chose XHTML because you think it makes your code better, right? Then why use a Doctype whose very purpose is to allow bad code?
That leaves XHTML 1.0 Strict and XHTML 1.1. The practical differences between them, as described by the W3C, are minimal.
According to the W3C, XHTML 1.1 should not be served with a MIME type of text/html. XHTML 1.0, however, may be served as text/html. Therefore I recommend that you do not use XHTML 1.1 (since Internet Explorer requires it to be sent as text/html).
Conclusion
The best choice for your website is almost certainly HTML 4.01 Strict.
If you have a specific need for XHTML, or are simply compelled to use it by some quaint notion of progress and purity, then use XHTML 1.0 Strict.
If you are stuck in the 90′s, with tags and , then use HTML 4.01 Transitional. But couldn’t I tempt you into trying CSS?
If you are using frames, then you probably ought to get your head examined; but you also need HTML 4.01 Frameset.
Some good pages about the reality of XHTML
Great article!
I started about a month ago switching sites back to HTML after years of THINKING I was creating XHTML (but all along using the wrong content-type).
Well Mike, I’m converted. Your sagacious advice will not go ignored, in fact, I’m bookmarking this article, and will send it on to any future clients who requested XHTML!
Referring to the HTML 5 document type (<!DOCTYPE html>) should be safe already, by the way. However, I’m feeling free to blatantly point to http://coderesponsibly.org/ in this context as well, albeit somehow off-topic.
Closing tags voluntarily has nothing to do with coding responsibly
Loved it.Superbly given arguments mate.You are very convincing indeed,damn you
Hello,
Good article!
Why did this site choose XHTML 1.0 Strict instead of HTML 4.01 Strict ?
Regards,
Kenneth
I appreciate the thought you put into this, so I wanted to share my own experience with xhmtl transitional so far. I want to move to strict for better parsing, but some of my customers are on slow 56kbps modems in the boondogs. It takes a while for the css to arrive, during which the layout jumps all over the place unless it contains height and width directives. By including height and width the layout is in place, so the page is readable while the images and menu tables are laying out. Ive read that’s actually the reason why trnasitional is still around, and Im not really a big expert, but I have seen that mentioned on w3c.org even I think.
Nice article, well written. Objective, to the points that matters.
very informative….must read
Great Job !
Thank you for an enlightening article.I’m just starting to build my first website.
Although you recommend using HTML 4.1 Strict;When I viewed the Page Source, it said XHTML 1.0 Strict. Can you please explain this to me.
I only wrote the article. This isn’t my website.
Nevertheless, XHTML 1.0 Strict is also a fine choice of doctype. I prefer HTML 4.01, for the reasons given in my article, but that doesn’t mean that XHTML is “wrong”.