What happens in Quirks Mode in web browsers?

What happens in Quirks Mode?

Quirks Mode is a mode of operation of web browsers such as Internet Explorer (IE), Firefox, and Opera. Basically, Quirks Mode (also called Compatibility Mode) means that a relatively modern browser intentionally simulates many bugs in older browsers, especially IE 4 and IE 5.

Quirks Mode is triggered by doctype sniffing, also known as doctype switching. This means that the browser inspects the start of an HTML document to see whether it contains a doctype declaration as required by HTML specifications.

The purpose of Quirks Mode is to make old pages to display as their author intended. Old pages may have been written to utilize known features of old browsers or at least to adapt to them. For more information about Quirks Mode in general, consult the QuirksMode.org site.

There is no authoritative specification of what happens in Quirks Mode. After all, the mode is, by essence, an intentional violation of CSS and HTML specifications. However, since authors may need a description of what may actually happen in Quirks Mode, I have composed this document.

If you have an existing page that seems to work well but lacks a doctype declaration (required by HTML specifications) at the beginning, you should not simply put such a declaration there. The reason is that the declaration makes browsers work in the so-called Standards Mode as opposite to Quirks Mode. This may mean just about anything. I have seen the entire content of a page disappear when you add a doctype declaration. More often, the layout changes in rather unexpected ways. Well, the ways are not that unexpected if you know what may happen in Quirks Mode.

Before adding a doctype declaration, you should check both the HTML and CSS code for syntactic correctness by using validators and checkers. This may not be enough, since the page might still have been written relying on things that just “work”—in Quirks Mode. Thus, you should test the page at least on IE 7 and Firefox 2 in Standards Mode, i.e. after adding a doctype declaration. If the page doesn’t work then, the following list might be useful for spotting the problem.

When creating a a new page, you need not know about Quirks Mode and should usually not think about it. Simply write according to HTML and CSS specifications; this includes using a doctype declaration that puts modern browsers into Standards Mode. Moreover, put the doctype declaration at the very start, since some browsers go to Quirks Mode, if there is anything (even a comment) before it. (This causes trouble if you are using XHTML, but in most cases, you shouldn’t use XHTML for web pages anyway, for the time being.) But if you decide to use some features that might only work in Quirks Mode, such as a height="100%" attribute for a table element, you should check the list for other possible implications.

In Quirks Mode, browsers have been observed to behave in the following ways, though not all browsers exhibit all of these features:

The box model is incorrect (different from CSS specifications, though perhaps intuitively more natural). This means that the width and height properties specify the dimensions of the entire element box, including padding and border, and not just the element’s content. (There is a demo later in this document.)

Dimensions of non-replaced inline elements (e.g., span elements by default) are affected by width and height properties (while by CSS specifications, they shall be ignored).

Percentage heights for elements (e.g., <table height="100%"> in HTML or table { height: 100% } in CSS) are applied, using the available height as reference, even when the enclosing block has height auto (the default). In Standards Mode, the height is determined by the requirements of the content; but percentage heights work when the enclosing block has its height set to a specific value.

Overflow is treated by expanding a box. When the content of an element does not fit into the dimensions specified for it (explicitly or implicitly), then overflow: visible (the default) means that the content overflows while the box dimensions are as specified. In Quirks Mode, the dimensions change; this can easily been seen e.g. if the box has a background color or a border.

The root element is the body element on IE in Quirks Mode. By the specifications, it is the html element. For example, setting a margin for body has no effect in Quirks Mode. As another example, IE has a vertical scrollbar by default, though it is inactive (dim) when there is nothing to scroll, and you can remove it (when it is not needed) in Quirks Mode by setting body { overflow: auto; }, but in Standards Mode, you need to add html { overflow: auto; } as well.

Padding for an image is ignored when set in CSS for an img element or an input type="image" element.

Default horizontal margin for a floated image is three pixels (instead of zero). That is, if the img element has the attribute align="left" or align="right" or if the CSS rule float: left or float: right applies to it, the browser behaves as if the img element had the attribute hspace="3" (or its margin-left and margin-right properties had the value 3px). This applies to IE; on other browsers, Quirks Mode may cause the extra margin on one side of the image only, and its width can be 2 pixels instead of 3.

Vertical alignment of an image is under certain conditions to the bottom of the enclosing box, not to the baseline of text. This happens when the image is the only content within an element, typically a table cell. This means that e.g. an image in a table cell is by default at the bottom of the cell in Quirks Mode (which is often what the author wants), whereas in Standards Mode there is a few pixels spacing below the image (unless one sets e.g.

vertical-align:
 bottom

for the img element).

Centering a block in CSS using e.g. margin: 0 auto does not work. Note: On IE (even IE 7), setting align="center in HTML or text-align: center in CSS for a div incorrectly centers inner block element as a whole, even in “standards mode.”

Font properties are not inherited from body or other enclosing elements into tables. This happens especially for font-size but may happen for font face, color, and line height as well. For example, if you set body { font-family: Arial }, it is possible that the font in table cells remains the browser default.

In a font size setting for a table cell, a percentage value is interpreted as relative to the browser’s basic font size, not to the font size that applies to the enclosing element (the table row) by CSS specifications.

Font size keywords are interpreted incorrectly so that medium is larger than the browser’s basic font size and small equals that basic font size. Similarly, the entire scale of keywords, xx-small, x-small, small, large, x-large, xx-large is interpreted systematically wrong: each value is interpreted as one step larger than it should.

Malformed property values are often interpreted on the basis of guesswork, e.g. margin: 10 as margin: 10px and color: ffffff as color: #ffffff. This violates mandatory error processing rules in CSS: a rule using syntactically incorrect value shall be ignored.

Case of letters is treated as insignificant in class and identifier selectors in CSS. Thus, the selector .foo matches an element with class="Foo" or class="FOO". By CSS specifications, the case is significant in these contexts.

Malformed names are accepted in class and identifier selectors. Specifically, names starting with a period or a number sign (e.g. in selectors .123a and #42) are accepted.

The declaration white-space: pre is ignored.

Fixed positioning is not supported: the declaration position: fixed is treated as position: static (on IE 7).

Many additions to CSS support (such as the max-width property and attribute selectors) in IE 7 are not in use Quirks Mode. That is, there are many CSS features that were not supported in IE 6 and are supported in IE 7, but only in Standards Mode. See Microsoft’s blog entry Details on our CSS changes for IE7.

Tag soup parsing. For example, if a document contains the markup
<p>text<table>...</table>
then e.g. Firefox treats, in Quirks Mode, the p element as containing the table element. In Standards Mode, the start tag of table implicitly closes the open p element. The difference can be seen if you e.g. set a border on the p element. Similarly, for example, Firefox accepts a ul element inside a font. IE always works by wrong rules in such issues, even in Standards Mode, but standards-conforming behavior can be achieved by using valid markup and always using explicit end tags like </p> even when they are formally optional.

White space between elements can be significant. For example, let’s say you have a list of links. Typically you would write the markup with line breaks between the list items, the li elements (that is, between </li> and <li> tags):

<ul>
<li><a ...>...</a></li>
<li><a ...>...</a></li>
...
</ul>

However, if you set display: block and a border for the link elements, you may wind up with vertical gaps (empty lines) between the boxes. This happens on IE 7 in Quirks Mode, and always on previous versions of IE. On the other hand, for the markup above, if you set display: inline for the li elements, then there is no white space between the element boxes on IE in Quirks Mode. In Standards Mode, and on other browsers, there is white space corresponding to one blank, and this is regarded as standards-conforming by some.

Forms have a default bottom margin of 1em in Mozilla browsers. (On IE, there is such a margin in both modes.) This is apparently meant to continue the tradition of web browsers to leave that much spacing below a form. It used to be a frequently asked question how to get rid of the empty line after a form.

Vertical margins are suppressed in some contexts, e.g. when a p element appears as the first element in a td element. This is more or less traditional behavior in browsers and takes place on IE 7in both modes (on IE 8, in Quirks Mode only).

The wbr markup for a line breaking opportunity is honored. Browsers have widely supported it, but IE 8 has stopped doing so in “standards mode.” This is bad news, since <wbr> tags have been the only effectíve way to suggest line break opportunities for otherwise unbreakable strings on web pages.

Mozilla browsers (like Firefox and Seamonkey) have some additional features, documented in the quirk.css file. For example, the default color for table borders is gray (as in most other browsers), as opposite to using the foreground color of the table as in Standards Mode. In such issues, Quirks Mode is really just a different mode for compatibility. Note: Not all the settings in that file apply to all versions of Mozilla.

The list is most probably not exhaustive. It relates mainly to IE 7. Other browsers may have a Quirks Mode that does simulate old versions of IE to the same extent.

Simple demo

The following simple images demonstrate one of the many differences between Quirks Mode and Standards Mode on Internet Explorer, namely the box model. They are presentations of the following markup in the two modes:
<div style="border: solid 2px #006; width: 8em; padding: 0 2em">stuff</div>

The explanation is that in Quirks Mode, the width property is (incorrectly) taken as specifying the total width of the element’s box, 8em in this case. In Standards Mode, it specifies the width of the content of the element, so that the total width of the box 12em (plus the widths of the borders). That is, the total width contains the left and right padding, each set to 2em.

On Firefox, the correct box model is applied in both modes. However, you can still simulate the incorrect box model used by IE in Quirks Model, by using the command CSS/Use Border Box Model in Web Developer Extension (which is a great tool in any CSS-related issues and many more).

An oddity in IE 7 and IE 8

On IE 7, if a a form element is preceded by a p element (a paragraph), omitting the optional end tag </p> tends to mess up some features of styling. If the form has a background set for it, the background will appear as a thin horizontal stripe only, on the top. There is a simple separate test page for this IE 7 bug. This bug has been observed on Opera, too.

The surprising thing is that this bug does not exist in previous versions of IE and, even more strangely, it exists in “Standards Mode” only. In Quirks Mode, the background is shown properly, though of course other Quirks Mode features may mess up a page.

Presumably, this bug is connected with the fake “XHTML orientation” in IE 7. This browser version, despite actually not supporting XHTML, imposes some XHTML-like restrictions on (non-XHTML) HTML documents! In XHTML, the end tag </p> is not optional. Another bug of this kind is that some valid entity references like &Omega are not interpreted properly but displayed literally by IE, since they lack the terminating semicolon, which is always required in XHTML. (This bug appears in both Standards Mode and in Quirks Mode.)

IE 8 does not exhibit this bug in some cases, but viewing the test page shows even stranger behavior. In Standards Mode, the browser shows a thin yellow stripe as if there were an extra empty form. In Quirks Mode, the stripe is not there but the form lacks yellow background, except for a narrow stripe at the very start.

The conclusion is that the old recommendation to use explicit end tags is very sound. Throughout the history of HTML, various browsers have failed to infer the closing tags properly, and there is probably no end to this madness.

Checking the mode

To check which mode (Quirks vs. Standards) a browser is in,

On Firefox, use the command View/Page Info (and see the General pane); or if you have Web Developer Extension, just check an icon in its toolbar (third icon from the right).

For IE, type javascript:alert(document.compatMode) in the address bar, and check whether the popup window then says CSS1Compat (indicating Standards Mode) or BackCompat (indicating Quirks Mode); alternatively, download and install the simple Quirks or Standards Mode Bookmarklet.