Use the Right Doctype

by Eric A. Meyer

For literally years now, authors have been faced with a difficult dilemma: should we write pages to conform to the W3C standards, or write them to account for browser bugs? There are strong cases to be made for either approach. In the former case, your pages will be more likely to work in the future, and are certainly more "pure," but typically browser didn't display them very well. In the latter case, the display was a little more predictable for contemporary browsers, and it was certainly easier to sell to management, but what about the future? Would a new browse r-- one with stricter standards compliance -- break the display of the pages due to their bugwards compatibility?

Not an easy choice for most of us. Well, guess what? There's a simple way to escape the vicious cycle of proprietary bugs and behaviors, and the first people to give it to you are none other than the Microsoft MacIE team. Its called "doctype switching," and it's going to make your life much easier.

What's a Doctype?

In case you aren't familiar with the DOCTYPE element, it's quite simply an element used to declare what language (and its level) a document uses, and optionally what document type definition (DTD) is to be used in its handling. In other words, the document type. For example, a fully compliant HTML4 document would bear this doctype:


On the other hand, a "loose" or transitional HTML4 document could have:


These element, by the way, usually appear on the very first line of a document.

Until now, DOCTYPE has been used mainly by HTML validators, so that they know which DTD to use in validating the document. Most authors probably didn't give DOCTYPE much thought, if any, and it's quite likely that the vast majority of pages which have a DOCTYPE got that way thanks to a point-and-click Web authoring program filling it in without asking. In a great many cases, Web pages don't have a DOCTYPE element at all.

Putting Doctypes to Use

Well you might wonder what difference this makes. From a purely practical standpoint, almost none at all: the Web obviously still works, either with or without doctypes.

But consider a browser which actually paid attention to the document type, and chose a course of action based on it. This browser could look at a document and say, "This document is declared as strictly compliant HTML, so I'll hold it to that standard. If it's malformed, I won't display it. If it's valid, I'll use the W3C standards to display it." This same browser could read a document and think," This document doesn't have a declared doctype. I'll assume that it's old, bugwards-compatible, and needs to be displayed as old, buggy browser would have displayed it."

This browser is Microsoft Internet Explorer 5 for the Macintosh.

Now authors can choose the rendering model they want to follow. Feeling pure? Write your documents strictly to the standards and give them a Strict DOCTYPE. MacIE5 will display them according to the standards. Would you rather follow the behavior of older browsers? Author to the bugs, use a less strict DOCTYPE, and MacIE5 will emulate legacy behaviors in displaying your documents.

The beauty of this mechanism is that it will preserve the look of most legacy documents while fully allowing authors to start authoring to standards. It gives everyone a chance to start over. Authors can learn the standards, not the browser bugs, and produce better documents. Vendors can implement standards without being forced to "break" existing pages. Everyone wins.

On page two, we'll see how doctype works and give you a few examples.

Pages: 1, 2

Next Pagearrow