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, intentional violations 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. (Browser vendors do not generally document Quirks Mode. There are some descriptions, such as The effects of quirks mode emulation about IE, by Microsoft, but such descriptions cover some aspects only.)
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=
attribute for
a table
element, you should check the list for other possible
implications.
canvas
element in Quirks Mode.
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.)
span
elements by default) are affected by
width
and
height
properties (while by CSS specifications,
they shall be ignored).<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.body
element
is 100%, as opposite to being determined by its content.
(If you want 100% height for body
in standards mode,
set html, body { height: 100% }
in CSS.)
cols=5
makes the area 5 characters wide
in Standards Mode but only 4 characters wide in Quirks Mode.
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.img
element has dimensions smaller than needed for the text,
e.g. as in <img src="x.png" alt="Some alt text" width="8"
height="9">
when x.png
does not exist.
Firefox
omits the text and shows a generic icon for a broken image only.
body
element
on IE in Quirks Mode. By the specifications, it is
the html
element. For example, setting a margin
or width 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.
border
property of the
html
element (e.g., html { border: 0; }
).
id
attribute values
are matched case-insensitively, so that e.g. the CSS selector
#foo
matches an element with id="Foo"
.
By the specifications, the match must be case-#foo
matches only an element with id="foo"
.
img
element or an
input type="image"
element.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-align:
bottom
for the img
element).
margin: 0 auto
does not work.
Note: On IE up to IE 7, setting
align="center"
in HTML
or text-align: center
in CSS
for a div
incorrectly
centers any inner block element as a whole,
even in Standards Mode. On IE 8, this happens in Quirks Mode only,
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.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.thin
,
medium
, and thick
have different meanings on IE.
For example, thin
is 1px in Standards Mode, 2px in
Quirks Mode.
bordercolor
attribute,
which is nonstandard but widely supported, is treated
differently in Quirks Mode vs. Standards mode by IE.
The colors appear differently, though this seems to be caused
by an effect on border style.
padding
or margin
properties, but affected by
width
and height
properties.
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.h1 { color: red; color: nonsense; }
may cause the entire rule to be ignored; by the specifications, the
correct setting color: red
shall prevail.
Such duplicate settings are often used in an attempt to
provide a fallback when using advanced CSS values, and this
often fails in Quirks Mode, because the fallback gets ignored.
The problem only appears within a CSS rule, so dividing
a rule into two parts would help.
For example, instead
of h1 { color: #ccc; color: rgba(255, 255, 255, 0.7); }
you would use
h1 { color: #ccc; }
h1 { color: rgba(255, 255, 255, 0.7); }
.foo
matches an element with class="Foo"
or
class="FOO"
. By CSS specifications, the case is significant
in these contexts..123a
and #42
)
are accepted.
white-space: pre
is ignored.position: fixed
is treated as
position: static
(on IE 7).
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.expression()
construct.
rowspan=0
or
colspan=0
is ignored in many browsers, even
if they support these settings in Standards Mode.
(They mean that the cell spans the rest of the row or column.
This was implemented in browsers relatively lately.)
<p>text<table>...</table>
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
element.
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.
<font color=red><table>...</table></font>
does not affect the color of text inside the table.
In Standards Mode, it does – even though the markup
is nonstandard (invalid according to all HTML specifications)!
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.
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.
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 7 in both modes (on IE 8, in Quirks Mode only).
The issue does not arise if the relevant elements have their vertical
margins set explicitly in CSS.
img
elements are based on
alt
attributes on some old-style browsers,
including IE 8 in Quirks Mode but not in Standards Mode.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
effective way to
suggest line break opportunities
for otherwise unbreakable strings on web pages.
getElementsByClassName
(which is well supported
by other browsers and included in HTML5).
Window
object
such as using (in JavaScript) window.foo
,
window['foo']
or just foo
to refer to
the element with id="foo"
is possible in Quirks Mode only in some versions of Firefox. (In version 15,
it however restored support to this legacy feature in both modes.)
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.
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>
Here is the element as presented by your current browser, for a quick check:
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 issue).
A paragraph with no end tag </p>
.
Rendering on IE 7 in “Standards Mode”:
On IE 7,
if a
form
element is preceded by
a p
element (a paragraph),
omitting the optional end tag </p>
may mess up some features of
styling. If the form
has a background set for it,
the background may appear as a thin horizontal stripe only, on the top.
If the form
has a border set for it, it may be drawn incorrectly,
excluding some part of the form.
There is a simple separate test page for this
IE 7 bug. This bug has been observed on Opera, too.
Whether the bug is triggered seems to depend on how the content of the
form starts, in terms of markup.
This bug does not exist in previous versions of IE.
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.)
In IE 8 and IE 9, this bug still exists, in different manifestations. When viewing the test page in Standards Mode, IE 8 shows a bordered thin yellow stripe as if there were an extra empty form before the real form. IE 9 does the same but displays the real form without background color and without border.
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.
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.
The meaning and use of this icon, as well as the compatibility mode
selection in the Page menu of IE 8, is obscure.
According to tooltip and help texts,
clicking on the icon toggles between compatibility mode and normal mode.
However, contrary to what we might expect, this is not at all the
same as switching between Quirks Mode and Standards Mode.
Some features of rendering may be affected, but crucial issues
such as box model are unaffected; they are based on the
doctype
declaration.
When it causes Standards Mode, the
“compatibility mode” means that IE 8 emulates IE 7 in some
issues. In Quirks Mode,
“compatibility mode” means emulating IE 5, more or less,
See
Microsoft’s complicated explanation of this feature
and their page
Defining Document Compatibility.
IE 9 has seven different rendering modes, with different
intermediate modes between Quirks Mode and Standards Mode.
Using a correct DOCTYPE
does not guarantee Standards Mode;
for various reasons, a page may still be rendered in a manner that simulates
IE 7 – though this isn’t nearly as bad as Quirks Mode.
Check
Henri Sivonen’s page
Activating Browser Modes with
Doctype for the whole story.
In IE 10, the old IE Quirks Mode is now called IE 5 Quirks Mode. Another Quirks Mode has been added, under the plain name Quirks Mode or the name HTML5 Quirks Mode, which better resembles the Quirks Modes of other browsers. It is briefly described in the Microsoft document HTML5 quirks mode. The mode is presumably meant to reflect what is defined as Quirks Mode in “HTML5”, which means in practice things like W3C HTML5 (which has notes about Quirks Mode scattered around) and Quirks Mode Living Standard and some other specification-like documents.
The bad news to people maintaining legacy pages is that lack
of DOCTYPE triggers this new Quirks Mode on IE 10. This means
that things may go badly wrong on very old-style pages that relied
on old quirks and IE-specific features (like the expression()
construct in CSS). The way to get the old IE Quirks Mode is to use the
following tag:
<meta http-equiv="X-UA-Compatible" content="IE=5">