What's In Your DOCTYPE?
When you create a web form in Visual Studio.NET using the canned "Web Form" template you might ask yourself, "What is this DOCTYPE declaration about?"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
What is this strange-looking beast?
To explain the purpose of this line we need to look further and dig deeper than the notion of ASP.NET web forms. A little bit of digression into history is in order.
Back in the days of fierce browser wars the major rivals, Microsoft and Netscape, were pumping features in their browsers. There was no talk of web standards or interoperability. Well, at least not much. Each developed its own document object model (which, by the way, is exactly why ASP.NET validation controls don't work client-side in anything but IE—they are centered on the Mcirosoft's object model). Ironically, web developers and designers ended up being victims of these wars because each browser had its own bag of tricks, and you had to learn how to grease Internet Explorer and Netscape so your code would somehow work in both. As a result, creative minds came up with code forks to serve different code snippets and style sheets to accommodate rendering inconsistencies, resorted to spacer gifs to fudge layouts, etc. The junk galore you see in 99% of web pages today reflects the chaos bred by the browser wars. Just view the page sources and see for yourselves. Yes, I'm talking to you, Mr. One-Pixel-Spacer-Dot-Gif.
Old pages were hopeless casualties of coding trickery. It was too late and too expensive to fix them. Engineers behind IE/Mac had a spark of ingenuity—they suggested to implement switching of the rendering mode, known as "DOCTYPE switching".
The idea is as follows: when a modern browser sees a
<DOCTYPE> element it either renders the page in the old, "bugwards-compatible", "quirks", or "transitional", mode or switches to rendering in strict accordance with web standards. Let's define these "modern browsers": Internet Explorer/Win 6, Netscape 6 & 7, Internet Explorer/Mac 5. Older browsers simply never knew about DOCTYPE tags, and therefore they ignore them. Kudos to Opera for getting it right all along without need of DOCTYPE!
Let's sum up what we know so far: old browsers didn't get to meet DOCTYPE so they ignore it and render content in the Quirks mode. Modern browsers are capable of rendering either in Quirks or Standards (strict) mode. How do they know which mode to use? It's all in the DOCTYPE declaration.
W3C has defined a number of DOCTYPEs (see List of valid DTDs). Each DOCTYPE declaration switches a modern browser to an appropriate mode.
A couple of interesting facts about DOCTYPE:
- A DOCTYPE declaration should be the first line, i.e. it precedes even
<html>. ASP.NET web forms have one or more server-side directives which don't count because they are not rendered on the client.
- The DOCTYPE tag needs not be closed.
An article on MSDN states that "This element [!DOCTYPE] is available in HTML as of Internet Explorer 3.0" and goes on to say, "You can use this declaration to switch Internet Explorer 6 and later into strict standards-compliant mode." I find it ironic that support for DOCTYPE hasn't been implemented until IE6/Win was released if the declaration itself has been there since IE3/Win.
"In standards-compliant mode, compatibility with other versions of Internet Explorer is not guaranteed. When standards-compliant mode is switched on, the rendering behavior of documents may be different in later versions of Internet Explorer."
If you've been following this discussion attentively, this statement should come as no surprise. Consider this to be a mini-quiz. Let's reiterate why this is so. The MSDN article talks about IE/Win 6 and therefore "other versions" are 5.5, 5.0, 4.x, 3.x, etc. Support for DOCTYPE has been around since IE 6 only. Therefore versions prior to IE/Win 6 always render in Quirks mode and cannot be switched into the Standards mode. IE/Win 6 can go both ways.
The Three Document Type Definitions (DTD)
The HTML 4.x spec defines three document type definitions (DTD): Strict, Transitional and Frameset:
- Strict "includes all elements and attributes that have not been deprecated or do not appear in frameset documents." (Document Type Definition)
- Transitional "includes everything in the strict DTD [Document Type Definition] plus deprecated elements and attributes (most of which concern visual presentation)." (Transitional Document Type Definition
- Frameset is for documents with frames. This mode is "identical to the HTML 4.01 Transitional DTD except for the content model of the "HTML" element: in frameset documents, the "FRAMESET" element replaces the "BODY" element." (Frameset Document Type Definition)
Why Bother With DOCTYPE?
The intention behind document switching is to ditch old practices and write standards-compliant code. By switching to the strict mode you can practice writing code that works the same way on all modern browsers. This goes for Internet-enabled devices many people simply overlook—PDAs, cell phones and other wireless accessories with limited rendering capabilities. Pages authored in the Standards mode will work much better than the Quirky ones. The Standards mode "excludes the presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attributes and elements is required" (see Document Type Definition). The bell tolls for you.
No, Wait, There Are Three Modes, Not Two!
As if the life of a developer wasn't complicated enough, let's add a dimension of complexity to the subject as hand. In all fairness, I have to say there are three rendering modes: Quirks, Standards, and Almost Standard. The third mode, Almost Standards, applies to the newest Gecko browsers.
"The Almost Standards mode is like the Standards mode except it addresses the issue of the... question [of gaps between image rows in tables when the layout engine is in the Standards mode] by rendering table cells with images in the traditional way. The mode is picked based on the doctype declaration (or the lack thereof) at the beginning of an HTML document."
Source: Mozilla Web Author FAQ
To make matters simple, I choose to keep this third mode in the back of my mind and pretend there are only two modes: Quirks and Standards. If you're shooting for XHTML with a Strict DTD you will probably never have to deal with the Almost Standards mode. Only if and when discrepancies rear their head do I worry about them.
The subject of which DOCTYPE is complete or incomplete, and which mode it triggers is a broad one. There is no reason to memorize them by heart. Simply look them up when you need them. Below are some useful resources in this regard:
- Jeffrey Zeldman's "Designing With Web Standards" Chapter 11 has a comprehensive discussion of DOCTYPEs, the history, reasoning and philosophy behind them.
- A bonus chapter to Eric Meyer's "Eric Meyer On CSS". A very thorough discussion of DOCTYPE switching and browser bugs you might encounter by switching form Quirks to Standards. See Picking a Rendering Mode
- A List of valid DTDs from W3C for copy-and-paste pleasure.
DOCTYPE in ASP.NET
Now that you know the history of DOCTYPE switching and the purpose thereof, let's take a look at a canned Visual Studio.NET "Web Form" template.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
This line tells you that web forms are rendered in the old, Quirks, mode. Why is it there? Personally I believe it's there to create awareness. Awareness that there is "a more excellent way". It is strange though that the there is no way to change the DOCTYPE in Visual Studio.NET except by hand. Feels like a job half-done.
A Thorny Transition
The transition from Quirks to Standards can be a thorny one. Ask yourself: why are there different rendering modes? To address browser bugs (the ones introduced back when nobody paid attention to web standards). The Standards mode exists to ensure that your design will look the same (well, acceptably the same) across modern browsers and web-enabled devices that will emerge in the future. Therefore you have to unlearn old tricks and embrace the doctrine of standards. It will pay off. This ship has sailed.
You will encounter some blatant inconsistencies in rendering, but Eric Meyer, Jeffrey Zelman and other prominent individuals cover your back (see links above). Online resources, such as Position Is Everything explain these differences in much detail.
I hope this article clarified for you what DOCTYPEs are and why we need them. In future articles I will go over other aspects of Web Forms. Until then, happy coding!