Friends don’t let friends use quirks mode
Having a doctype in your webpage isn’t just about making your webpage validate. The most important practical reason to include one is to make sure the browsers are rendering in standards compliance mode.
Most browsers have two modes for displaying webpages, standards mode and quirks mode. Webpages with a doctype are rendered using standards mode, which is broadly the same* for each browser because it follows the standards set out by the W3C. Pages without a doctype are rendered using quirks mode, a backwards compatibility mode that will make the browser act like its earlier (less standards compliant) versions.
The problem with quirks mode is that each browser has its own quirks rendering rules that are different from all of the others. If this sounds like a flashback to the 1990s browsers wars, this is deliberate. The backwards compatible is with the browser versions that caused web developers so much headache in the late nineties.
For example, one of the most common problems with quirks mode is that IE renders the dimensions of each element differently to the other browsers. The HTML standards say that padding, borders and margins should be added to total width set on the element. So an element with a width of 100px and padding-left and padding-right set to 10px would have a complete width of 120 pixels. In quirks mode IE considers that padding, margins and borders are included in the width set on the element. So our element with a width of 100px and padding set to 10px would still have a complete width of 100px.
Here is a simple quirks mode example to demonstrate the problem. I want to use absolute positioning to display two div elements next to each other. Without a doctype, positioning correctly in IE means overlapping content in Firefox:

When I add a doctype to the page to trigger standards mode, I can use the same code to get the same positioning effect in both browsers:

I’m not picking on IE here because quirks mode isn’t something that is unique to IE. Firefox, Opera and Safari all have their own quirks mode rendering as well and each browser’s quirks mode has different rendering rules.
Using quirks mode can sometimes seem tempting because some of the quirks actually are easier to use than the standards alternatives, but I just want to warn you that this is a path of pain. For anything but the simplest pages you will effectively end up with several versions of your page targeting different browsers all woven into the same HTML file like some brilliant Rube Goldberg machine. This will be a maintenance nightmare and will get worse as your pages evolve to be more complex. I will repeat for emphasis: path of pain. You will still run into browser short comings using standards mode, but at least standards mode will allow you to have more page than hack.
Warning for VS2003 users:
Here’s a warning for people using Visual Studio 2003, or have pages that were originally created using it. The doctype that is generated in the default template is not a complete doctype and will not trigger standards mode in the browser.

January 22nd, 2008 at 9:02 am
I remember reading a post from a Microsoft dev about IE quirks mode and non quirks mode. It basically said this if you are not using quirks mode, then you are game to having your website broken for every update to internet explorer that MS releses as they reinterpret the W3C rules. Quirks mode on the other hand is less likely to break because MS does a lot of backward compatability testing with existing websites.
So under that assumption, does quirks mode not serve a purpose? I would think that most intranet sites where content gets refreshed constantly, but not nescessarily the design of the page – Quirks mode may be a better choice.
At least that is my experience as I’ve had a website running under quirks mode since 1999 (Ajax enabled by the way though we didn’t call it that then) with no need to update the HTML due to browser rendering issues.
January 22nd, 2008 at 2:54 am
That’s a fair point. The big advantage is cross browser compatibility and that’s not an issue for everyone.
One question to ask is whether you will need to support more browsers in the future. Some of the code that I maintain was written to be IE only in 2001 and now has to support other browsers as well. Retrofitting cross browser compatibility is a very unpleasant process.
I think your risk of having your code broken by a newer version of IE is probably related to how far you’re pushing the browser. A simple content website probably doesn’t need to worry too much while it is more likely to be a problem for a complicated web application. Interestingly enough, from IE8 onwards there will be a way to tell the browser which version you’re targeting so it shouldn’t be a problem anymore (http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx).
I guess any decision is always about making the right tradeoffs for your project. Thanks for the insightful comment. :)