Use the Right Doctype

O’Reilly Network

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: 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
   "http://www.w3.org/TR/REC-html40/strict.dtd">

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

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.

How Does It Work?

It's quite simple. If you want a document to be interpreted in "strict" mode, you have to do two things:

  1. Insert a DOCTYPE which claims a strict DTD in your document, or a transitional DTD with a URL pointing to that DTD.
  2. Make sure your document is well-formed and valid.

That's all. The second is really a follow-on to the first, but it's important. If you do claim that the document uses a strict DTD, you need to make sure that it follows that DTD. If it doesn't, the page could get very badly mangled, or possibly even refuse to display at all, and it will be your fault.

If you aren't interested in having your HTML documents held to such a standard, then you can do one of two of things:

The second case is useful if you want to validate your documents, but don't want them to be strictly standards-compliant. The first is useful if you're just slamming out pages which you aren't going to bother validating, and don't want to be strictly interpreted.

How About Some Examples?

Here are a few situations, and the effects they'll have in MacIE5:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
MacIE5 will go into "strict" mode.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
MacIE5 will go into "strict" mode, thanks to the URL. However, authors are encouraged to avoid this behavior, since it's entirely possible that some day transitional documents will be classified as quirky instead of strict.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
MacIE5 will go into "quirky" mode.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN";>
MacIE5 will go into "quirky" mode. Any HTML DTD before version 4 will trigger "quirky" mode.

(No DOCTYPE at all.)
MacIE5 will go into "quirky" mode for HTML documents.

Note that last point there. By default, HTML documents are taken to be quirky, unless one of the "strict" triggers is found. XML documents, on the other hand, are treated as strict by default.

So What's the Difference?

Besides the simple difference that strict documents will be treated differently, strict documents will have two big differences from quirky ones. First is that all elements will inherit styles, including table elements, which have a hard time inheriting text colors and styles in quirky mode. Second is that font-size: medium text will be the same size as unstyled text. In quirky mode, unstyled text is the same size as small.

There may be other differences, but they are not likely to be documented. Why not? Because as we move forward, authors should stop relying on bugwards behavior. The safety net is still there, but it won't be there forever.

Conclusion

Thanks to the efforts of the MacIE team at Microsoft, authors now have a way to break free of bugwards authoring, and the chance to start using standards without fearing for their older documents' appearance. And lest you fear that this will be another point of incompatibility, the team at Netscape has plans to offer this same mechanism in Netscape 6. With these two browser titans offering authors the same escape route, we may finally see standards get the kick-start they need.