Nimbupani Designs

The Truth about Doctypes

I knew I had to declare a Doctype but just didn’t know why. I recently had to work with html files without Doctype and didn’t even realise that the IE errors I was coming across was because of the triggering of quirks mode. Today I read in depth about Doctypes and I burn in shame to know how many bugs could simply be resolved by declaring a Doctype. So, here is what I found out about the Damned Doctypes.

IN THE BEGINNING

Long long time ago in the age of no standards, people wrote HTML with reckless abandon which resulted in tag soups and atrocious styling. Browsers were no better and tried to “fix” the errors in CSS declarations and generally did not obey any standard.

ENTER DOCTYPE

In 1995 the first signs of standardisation came in the form of HTML 2.0 HTML specification (note that there was no HTML 1.0) which first introduced the use of Doctype “To identify information as an HTML document conforming to this specification, each document must start with … document type declarations.”

At end of December 1997, HTML 4.0 was released which specified 3 different specifications. A HTML document can choose which one to follow, by indicating with the Doctype: A Strict specification (which excludes deprecated elements and frames), a Transitional specification (which excludes only frames), and a Frameset specification (which allows just about anything!).

INVENTION OF DOCTYPE SWITCHING

With the 3 flavours of HTML 4.0, browsers had the burden of having to display non-confirming HTML like it used to before (as many old websites would break if the browsers changed the CSS and HTML implementation to match the standards) as well as new HTML documents produced to confirm to the specifications.

Tantek Çelik, first implemented the innovative Doctype Switching while working on Internet Explorer 5 for Mac. The idea was this, if the Doctype specifies one of the modern specifications, the browser will render the HTML in “standards mode” and if not, the browser will render the HTML in “quirks mode”. Soon, all other browsers adopted it.

There is a 3rd mode called “Almost Standards Mode” which only differs from “Standards Mode” in the implementation of vertical sizing of table cells (IE 6 and 7 only render this mode and never the standards mode).

QUIRKS MODE

When a browser renders a document in quirks mode, it interprets the CSS and HTML like older versions of the browser allowing for nonstandard code and workarounds. The most affected is the CSS of the HTML document which gets interpreted differently in this mode.

There is no standard on which Doctype will trigger quirks mode, each browser has its own list of Doctypes that will trigger the quirks mode (see this chart).

For IE 6, 7 and 8, the Doctype declaration should be the very first line of the HTML document, otherwise it defaults to quirks mode (An XML declaration before an XHTML Doctype or even having a HTML comment above the Doctype declaration will trigger quirks mode). In IE 7 and 8, having an XML declaration as the first line of the HTML document will no longer trigger quirks mode.

Here is how valid CSS declarations get misinterpreted in IE 6, 7 and 8, when they are in quirks mode:

  • The Box Model is rendered incorrectly (padding is applied within the declared width of an element instead of being added to the declared width of an element).
  • The dimensions of a block level element changes if the content of the element does not fit the declared dimensions (e.g. If a paragraph which has a height:200px; specified will expand in IE 6 and 7 in quirks mode if the actual text content is longer than that declared height).
  • The default margin-left and margin-right of a floated element becomes 3px in IE.
  • margin:0 auto does not center elements.
  • Font properties are not inherited from parent elements to tables.

Other browsers have their own set of weird behaviors in quirks mode.

FUN TIMES WITH IE 8

As IE 6 and IE 7 “standards” mode did not fully confirm to the specifications, many websites had “hacks” to make them “look good” in “standards mode”. These websites will all appear “broken” in IE 8 when that comes along (since it complies more to standards than before), so here we go AGAIN down the road of Doctype switching.

So, now IE 8 has at least 4 modes, quirks mode, IE 7 standards mode, IE 8 almost standards mode and IE 8 standards mode.

Now IE 8 wants to introduce a NEW switching mechanism by using the <meta http-equiv="X-UA-Compatible" content="IE=8" /> declaration to make sure it uses the IE 8 standards mode to render. If this meta declaration does not exist, it will use other various sources to determine which mode to render, most likely defaulting to IE 7 standards mode.

SO THE POINT IS

Just use the damned Doctype to make sure browsers don’t default to quirks mode with your HTML documents. You are safe in using:

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> (except it triggers quirks mode in Konqueror 3.2, matters only if you know and care about that browser).
  • <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> (without the XML prolog)

I hope this is of some use to you when you go about coding your HTML pages. Remember the damned Doctype!

REFERENCE

1. CSS - Quirks mode and strict mode

2. Activating Browser Modes with Doctype

[UPDATED: I edited the information about Doctype switching with inputs from Russ Weakley.]

Comments

Comments are closed for this post. Please message me on twitter, if you would like to comment.
 
Guest's picture

well .. nice post !

On a side note ..

the problem with xhtml-transitional or strict is that , it all looks perfect until u plug in 3rd party code.

Validation breaks and it hurts from a purist’s perspective

 
divya's picture

Thanks!

The problem with XHTML is best explained here: http://hixie.ch/advocacy/xhtml

 
Guest's picture

Ah yes, I recognize a kindred soul in Varun’s hating on XHTML-strict. My own long rant is here

Divya - Mark Pilgrim had the best explanation of the problems(and necessity) of serving XHTML as text/html and not application/xhtml+xml - see his thought experiment article.

 
Guest's picture

Hey divya, how about replacing XHTML 1.1 doctype with XHTML 1.0 Strict instead?

Since XHTML 1.1 must be served in MIME type application/xhtml+xml, it will automatically trigger standards mode in browsers which support the MIME type, with or without doctype. XHTML 1.1 doctype only serves to validate the code output.

And as it’s wrong(in a W3C kind of way) to be serving XHTML 1.1 as text/html, I suggest XHTML 1.0 Strict, emphasizing on the Strict validation and also works legit with text/html.

Great post by the way!

 
divya's picture

Ha ha the thought experiment article is really good! I started off with XHTML too, but I soon switched to HTML coz after all my documents *are* HTML. Another post on that topic soon!

 
divya's picture

@draco: Actually XHTML 1.1 spec does allow content-type text/html if it satisfies compatibility guidelines.

Thanks for the comment!

 
Guest's picture

@divya ah I stand corrected. I didn’t know, thanks for highlighting that!

 
Guest's picture

Ugh! I thought standards were supposed to be standard!

 
Guest's picture

Very nice design

 
Guest's picture

If your only intention is to trigger standards mode (which is the only thing that doctypes are generally used for,) you can do that by simply doing this:

<!DOCTYPE html>

 
divya's picture

@Issac, Yeah that does make sense. If people are actually interested in validating their documents, probably they are better off using one of the three above (since <!DOCTYPE HTML> will trigger the HTML 5 validator.