Quirks mode and strict mode

Quirks mode and strict mode are the two ’modes’ modern browsers can use to interpret your CSS. This page gives a short overview of the reasons for and the differences between these two modes.

The problem

When Netscape 4 and IE 4 implemented CSS, their support did not match the W3C standard (or, indeed, each other). Netscape 4 had horribly broken support. IE 4 came far closer to the standard, but didn’t implement it with complete correctness either. Although IE 5 Windows mended quite a lot of IE 4 bugs, it perpetuated other glitches in CSS (mainly the box model).

To make sure that their websites rendered correctly in the various browsers, web developers had to implement CSS according to the wishes of these browsers. Thus, most websites used CSS in ways that didn’t quite match the specifications.

Therefore, when standards compliancy became important browser vendors faced a tough choice. Moving closer to the W3C specifications was the way to go, but if they’d just change the CSS implementations to match the standards perfectly, many websites would break to a greater or lesser extent. Existing CSS would start to show odd side effects if it were suddenly interpreted in the correct way.

So moving closer to standards compliance would cause problems. On the other hand, not moving closer to standards compliance would perpetuate the general confusion of the Browser Wars Era.

The solution

Therefore any solution to this problem had to

allow web developers who knew their standards to choose which mode to use. continue displaying old pages according to the old (quirks) rules.

In other words, all browsers needed two modes: quirks mode for the old rules, strict mode for the standard. IE Mac was the first browser to implement the two modes, and IE Windows 6, Mozilla, Safari, and Opera followed suit. IE 5 Windows, as well as older browsers like Netscape 4, are permanently locked in quirks mode.

Choosing which mode to use requires a trigger, and this trigger was found in ’doctype switching’. According to the standards, any (X)HTML document should have a doctype which tells the world at large which flavour of (X)HTML the document is using.

Old pages written before (or in spite of) the standardization wave don’t have a doctype. Therefore ’no doctype’ would mean quirks mode: show according to old rules.

Contrarily, if the web developer was savvy enough to include a doctype, he probably knew what he was doing. Therefore most doctypes trigger strict mode: show according to pure standards.

Any new or unknown doctype triggers strict mode.

The problem was that some pages written in quirks mode did have doctypes. Therefore each browser has its own list with doctypes that trigger quirks mode. See this browser comparison chart for an overview of these lists.

Note that your page does not have to validate according to the chosen doctype, the mere presence of the doctype tag is enough to trigger strict mode.

On this site I use this doctype in most pages. In addition to declaring my pages XHTML 1.0 Transitional, it also triggers almost strict mode in all browsers.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Good solution?

Personally I’m not terribly happy with doctype switching. A doctype carries information about the flavour of (X)HTML you’re using, in other words, about document structure. In my opinion it shouldn’t carry any information about document presentation, because that violates the separation of structure and presentation that CSS is all about.

But the browser vendors were not to be denied: browser after browser implemented doctype switching, and nowadays all modern browsers support it.

Complication: almost strict mode

In the early days, experiments with strict mode invariably raised the comment that images suddenly got an odd bottom margin that couldn’t be removed. The cause was that in strict mode <img /> is an inline element, which means that some space should be reserved for possible descender characters like g, j, or q. Of course an image doesn’t have descender characters, so the space was never used, but it still had to be reserved.

The solution was to explicitly declare images block level elements: img {display: block} .

Nonetheless browser vendors, Mozilla especially, thought this was such a confusing situation that they introduced "almost strict mode". This was defined as strict mode, but with images continuing to be blocks, and not inline elements.

Most common doctypes, including the one I use, trigger almost strict mode. The treatment of images is by far the most important difference between almost strict mode and really strict mode.

IE Windows special: the xml prolog

In IE 6 Windows, Microsoft implemented one extra rule: if a doctype that triggers strict mode is preceded by an xml prolog, the page shows in quirks mode. This was done to allow web developers to achieve valid pages (which require a doctype) but nonetheless stay in quirks mode.

This is the xml prolog. You should put it on the very first line of your document, before the doctype.

<?xml version="1.0" encoding="iso-8859-1"?>

Note that this behaviour has been removed from IE 7.

The differences

What, exactly, are the differences between the two modes? There are a few more differences that can trip up the unwary web developer. The table below summarizes a few of the most important ones.

IE Quirks Mode is IE5.5, by the way. IE6, 7 and 8 all switch back to 5.5 when they encounter a Quirks Mode page.

Always Always supports standard Never Never supports standard Depends Standards support depends on rendering mode; see text for details

Further information can be found at Jukka K. Korpela’s Quirks Mode features page.