Mozilla Quirks Mode Behavior

  • Revision slug: Mozilla_Quirks_Mode_Behavior
  • Revision title: Mozilla Quirks Mode Behavior
  • Revision id: 50264
  • Created:
  • Creator: DBaron
  • Is current revision? No
  • Comment 28 words added

Revision Content

The following is a rough list of the differences that exist between Mozilla's standards mode and quirks mode behavior. This list is current as of early June 2001 (with additions since then, but not a complete list of the changes since then). Since that time the most significant change has been that many of the form control-related quirks have been removed.

Miscellaneous & Style

  • All of the style rules in {{ Source("layout/style/quirk.css") }} apply.
  • In quirks mode css class names are case insensitive. In standards mode they are case sensitive.  (This also applies to getElementsByClassName.)
  • Stylesheets linked in the document with an advisory mime type of text/css will still be treated as CSS even if the server gives a Content-Type header other than text/css.
  • The CSS parser accepts colors not beginning with #.
  • {{ obsolete_inline("1.9.2") }} HTML colors were parsed differently up to Gecko 1.9.2 {{ geckoRelease("1.9.2") }} ({{ Bug("121738") }}).  
  • The CSS parser interprets unitless numbers as px (except for font-size because that was what Netscape Navigator 4 did, and except for line-height and any other properties where they have distinct meaning).
  • An empty string for the background attribute sets the background URL to empty only in quirks mode.
  • The topmargin, bottommargin, leftmargin, and right margin attributes on body are supported only in quirks mode.
  • {{ gecko_minversion_inline("1.5") }} (Mozilla Suite 1.5) The scrollLeft, scrollTop, scrollWidth, and scrollHeight properties are relative to body in quirks mode (instead of html)  ({{ Bug("211030") }}
  • {{ gecko_minversion_inline("0.9.6") }} (Mozilla Suite 0.9.6) In quirks mode, the URL fragment <code>#top</code> scrolls to the top of the page when there is no such anchor ({{ Bug("80784") }}
  • System fonts work differently in quirks mode (shouldn't the form controls that use them be the ones working differently instead?).
  • HTML (1-7) and CSS (xx-small - xx-large) font sizes are calculated slightly differently (see {{ Bug("18136") }}).
  • List bullets do not inherit the font size of the list in quirks mode.
  • The :hover pseudoclass will only be applied to links, images, and form controls, unless the selector includes tag names, ids, or attributes.
  • {{ obsolete_inline("6.0") }} Prior to Gecko 6.0 {{ geckoRelease("6.0") }}, the :hover pseudoclass was not applied to class selectors; for example, .someclass:hover did not work. Starting in Gecko 6.0, this quirk has been removed.
  • Undetected document.all support.

Block and Inline layout

  • [This quirk is present in almost standards mode.] Line height (not line-height) calculations are different to fix {{ Bug("5821") }} and {{ Bug("24186") }} (some other issues are described in {{ Bug("22274") }}).
  • There are a bunch of quirks to get percentage heights on images, tables, objects, and applets (etc.?) to "work" (the way they did in Netscape Navigator 4), even though CSS says that percentage heights should behave like 'auto' heights when the parent element doesn't have a fixed height. See {{ Bug("33443#c9") }}. See also {{ Bug("41656") }} and its duplicates. Some of these quirks may cause other effects (see {{ Bug("54119") }}).
  • The HR element is treated differently in quirks and strict mode (and arguably wrong in both).
  • {{ obsolete_inline("8.0") }} Prior to Gecko 8.0 {{ geckoRelease("8.0") }} text-decoration in quirks mode had line thickness and position adjusted on descendant text to match the descendant
  • In quirks mode, the font element changes the color of text decorations specified on ancestor elements
  • In quirks mode, text-decoration is propagated into floating and absolutely positioned elements
  • In quirks mode, text-decoration is not propagated into tables

Tables

  • In quirks mode absmiddle (handled incorrectly?) and middle (perhaps incorrectly as well?) are accepted as values of align on table cells, and absmiddle, abscenter, and middle are supported on tables (treated the same as center).
  • TD, TH, TR, THEAD, TBODY, and TFOOT elements have the document background (and color?) applied to them (when the document background is specified in certain ways?) (see also {{ Bug("70831") }} ).
  • The empty-cells property defaults to hide in quirks mode but show (according to CSS2 errata) in strict mode (see {{ Bug("33244") }}) (though the correct fix would be to specify it on the HTML TABLE element in quirk.css).
  • In quirks mode floated tables never move to the next "line" if they don't fit next to other floats, they just keep widening the page (see {{ Bug("43086") }}).  To correspond, their width is computed as though only the remaining available space is the containing block width.  ({{ Bug("99461") }})
  • In quirks mode colspan="0" and rowspan="0" are intentionally not handled as described in HTML4.
  • hspace and vspace are supported on TABLE only in quirks mode.
  • In quirks mode, when tables have a border style of inset or outset, the border color is based on the background color of the table or of the nearest ancestor with non-transparent background.
  • In quirks mode table cells with a border have a minimum width of one pixel.
  • In quirks mode a fixed width specified on a table cell resets the nowrap attribute. If the nowrap attribute is present the cell width will never be smaller than the specified fixed width ({{ Bug("277232") }}) .
  • The basic table layout strategy ignores padding (on what) in quirks mode.
  • The basic table layout strategy handles widths differently in some way.
  • In quirks mode, percentage values are supported on the cellspacing attribute, but treated as pixels {{ bug("106336") }}

Forms

  • Button inputs calculate their size differently.
  • In standard mode a BUTTON element (?) can submit only if it lacks a type attribute.
  • Text inputs (and other form controls containing text???) calculate their size differently. (see {{ bug|X }} for the description of the original fix and also {{ bug|X }} for suggested modifications)
  • The fonts for button INPUT elements and SELECT elements are computed differently.
  • The requirement of HTML that one button in a radio group is always selected (by default) is not enforced in quirks mode.

Frames

  • In quirks mode marginwidth and marginheight on a FRAME are propagated to the contained BODY.
  • In a frame size specification 0* is treated as 1* (see {{ Bug("40383") }}).
  • The scrolling attribute on FRAME is handled differently.

HTML Parser

  • In quirks mode, we parse HTML comments in a way compatible with older browsers instead of treating "--" as the comment start and end delimiter. [This quirk has been adopted in standards mode {{ Gecko_minversion_inline("2.0") }} {{ geckoRelease("2.0") }} ]

Original Document Information

  • Author(s): David Baron, Boris Zbarsky
  • Last Updated Date: July 8, 2003

See also

Mozilla's Quirks Mode

{{ languages( { "fr": "fr/Comportement_du_mode_quirks_de_Mozilla", "ja": "ja/Mozilla_Quirks_Mode_Behavior" } ) }}

Revision Source

<p>The following is a <em>rough</em> list of the differences that exist between Mozilla's standards mode and quirks mode behavior. This list is current as of early June 2001 (with additions since then, but not a complete list of the changes since then). Since that time the most significant change has been that many of the form control-related quirks have been removed.</p>
<h2>Miscellaneous &amp; Style</h2>
<ul> <li>All of the style rules in {{ Source("layout/style/quirk.css") }} apply.</li> <li>In quirks mode css class names are case insensitive. In standards mode they are case sensitive.  (This also applies to getElementsByClassName.)</li> <li>Stylesheets linked in the document with an advisory mime type of <code>text/css</code> will still be treated as CSS even if the server gives a <code>Content-Type</code> header other than <code>text/css</code>.</li> <li>The CSS parser accepts colors not beginning with <code>#</code>.</li> <li>{{ obsolete_inline("1.9.2") }} HTML colors were parsed differently up to Gecko 1.9.2 {{ geckoRelease("1.9.2") }} ({{ Bug("121738") }}).  </li> <li>The CSS parser interprets unitless numbers as <code>px</code> (except for <code><a href="/en/CSS/font-size" title="en/CSS/font-size">font-size</a></code> because that was what Netscape Navigator 4 did, and except for <code><a href="/en/CSS/line-height" title="en/CSS/line-height">line-height</a></code> and any other properties where they have distinct meaning).</li> <li>An empty string for the <code>background</code> attribute sets the background URL to empty only in quirks mode.</li> <li>The topmargin, bottommargin, leftmargin, and right margin attributes on body are supported only in quirks mode.</li> <li>{{ gecko_minversion_inline("1.5") }} (Mozilla Suite 1.5) The <code>scrollLeft</code>, <code>scrollTop</code>, <code>scrollWidth</code>, and <code>scrollHeight</code> properties are relative to <code>body</code> in quirks mode (instead of <code>html</code>)  ({{ Bug("211030") }}</li> <li>{{ gecko_minversion_inline("0.9.6") }} (Mozilla Suite 0.9.6) In quirks mode, the URL fragment &lt;code&gt;#top&lt;/code&gt; scrolls to the top of the page when there is no such anchor ({{ Bug("80784") }}</li> <li>System fonts work differently in quirks mode (shouldn't the form controls that use them be the ones working differently instead?).</li> <li>HTML (1-7) and CSS (<code>xx-small</code> - <code>xx-large</code>) font sizes are calculated slightly differently (see {{ Bug("18136") }}).</li> <li>List bullets do not inherit the font size of the list in quirks mode.</li> <li>The <code>:hover</code> pseudoclass will only be applied to links, images, and form controls, unless the selector includes tag names, ids, or attributes.</li> <li>{{ obsolete_inline("6.0") }} Prior to Gecko 6.0 {{ geckoRelease("6.0") }}, the <code>:hover</code> pseudoclass was not applied to class selectors; for example, <code>.someclass:hover</code> did not work. Starting in Gecko 6.0, this quirk has been removed.</li> <li>Undetected <code>document.all</code> support.</li>
</ul>
<h2>Block and Inline layout</h2>
<ul> <li><strong>[This quirk is present in almost standards mode.]</strong> Line height (not <code>line-height</code>) calculations are different to fix {{ Bug("5821") }} and {{ Bug("24186") }} (some other issues are described in {{ Bug("22274") }}).</li> <li>There are a bunch of quirks to get percentage heights on images, tables, objects, and applets (etc.?) to "work" (the way they did in Netscape Navigator 4), even though CSS says that percentage heights should behave like 'auto' heights when the parent element doesn't have a fixed height. See {{ Bug("33443#c9") }}. See also {{ Bug("41656") }} and its duplicates. Some of these quirks may cause other effects (see {{ Bug("54119") }}).</li> <li>The <code>HR</code> element is treated differently in quirks and strict mode (and arguably wrong in both).</li> <li>{{ obsolete_inline("8.0") }} Prior to Gecko 8.0 {{ geckoRelease("8.0") }} <code><a href="/en/CSS/text-decoration" title="en/CSS/text-decoration">text-decoration</a></code> in quirks mode had line thickness and position adjusted on descendant text to match the descendant</li> <li>In quirks mode, the <code>font</code> element changes the color of text decorations specified on ancestor elements</li> <li>In quirks mode, <code><a href="/en/CSS/text-decoration" title="en/CSS/text-decoration">text-decoration</a></code> is propagated into floating and absolutely positioned elements</li> <li>In quirks mode, <code><a href="/en/CSS/text-decoration" title="en/CSS/text-decoration">text-decoration</a></code> is <em>not</em> propagated into tables</li>
</ul>
<h2>Tables</h2>
<ul> <li>In quirks mode <code>absmiddle</code> (handled incorrectly?) and <code>middle</code> (perhaps incorrectly as well?) are accepted as values of <code>align</code> on table cells, and <code>absmiddle</code>, <code>abscenter</code>, and <code>middle</code> are supported on tables (treated the same as <code>center</code>).</li> <li><code>TD</code>, <code>TH</code>, <code>TR</code>, <code>THEAD</code>, <code>TBODY</code>, and <code>TFOOT</code> elements have the document background (and color?) applied to them (when the document background is specified in certain ways?) (see also {{ Bug("70831") }} ).</li> <li>The <code>empty-cells</code> property defaults to <code>hide</code> in quirks mode but show (according to CSS2 errata) in strict mode (see {{ Bug("33244") }}) (though the correct fix would be to specify it on the HTML <code>TABLE</code> element in <code>quirk.css</code>).</li> <li>In quirks mode floated tables never move to the next "line" if they don't fit next to other floats, they just keep widening the page (see {{ Bug("43086") }}).  To correspond, their width is computed as though only the remaining available space is the containing block width.  ({{ Bug("99461") }})</li> <li>In quirks mode <code>colspan="0"</code> and <code>rowspan="0"</code> are intentionally not handled as described in HTML4.</li> <li><code>hspace</code> and <code>vspace</code> are supported on <code>TABLE</code> only in quirks mode.</li> <li>In quirks mode, when tables have a border style of <code>inset</code> or <code>outset</code>, the border color is based on the background color of the table or of the nearest ancestor with non-transparent background.</li> <li>In quirks mode table cells with a border have a minimum width of one pixel.</li> <li>In quirks mode a fixed width specified on a table cell resets the <code>nowrap</code> attribute. If the <code>nowrap</code> attribute is present the cell width will never be smaller than the specified fixed width ({{ Bug("277232") }}) .</li> <li>The basic table layout strategy ignores padding (on what) in quirks mode.</li> <li>The basic table layout strategy handles widths differently in some way.</li> <li>In quirks mode, percentage values are supported on the cellspacing attribute, but treated as pixels {{ bug("106336") }}</li>
</ul>
<h2>Forms</h2>
<ul> <li>Button inputs calculate their size differently.</li> <li>In standard mode a <code>BUTTON</code> element (?) can submit only if it lacks a <code>type</code> attribute.</li> <li>Text inputs (and other form controls containing text???) calculate their size differently. <span class="comment">(see {{ bug|X }} for the description of the original fix and also {{ bug|X }} for suggested modifications)</span></li> <li>The fonts for button <code>INPUT</code> elements and <code>SELECT</code> elements are computed differently.</li> <li>The requirement of HTML that one button in a radio group is always selected (by default) is not enforced in quirks mode.</li>
</ul>
<h2>Frames</h2>
<ul> <li>In quirks mode <code>marginwidth</code> and <code>marginheight</code> on a <code>FRAME</code> are propagated to the contained <code>BODY</code>.</li> <li>In a frame size specification <code>0*</code> is treated as <code>1*</code> (see {{ Bug("40383") }}).</li> <li>The <code>scrolling</code> attribute on <code>FRAME</code> is handled differently.</li>
</ul>
<h2>HTML Parser</h2>
<ul> <li>In quirks mode, we parse HTML comments in a way compatible with older browsers instead of treating "<code>--</code>" as the comment start and end delimiter. <strong>[This quirk has been adopted in standards mode</strong> {{ Gecko_minversion_inline("2.0") }} {{ geckoRelease("2.0") }} <strong>]</strong></li>
</ul>
<div class="originaldocinfo">
<h3 name="Original_Document_Information">Original Document Information</h3>
<ul> <li>Author(s): David Baron, Boris Zbarsky</li> <li>Last Updated Date: July 8, 2003</li>
</ul>
</div>
<h3>See also</h3>
<p><a href="/en/Mozilla's_Quirks_Mode" title="en/Mozilla's_Quirks_Mode">Mozilla's Quirks Mode</a></p>
<p>{{ languages( { "fr": "fr/Comportement_du_mode_quirks_de_Mozilla", "ja": "ja/Mozilla_Quirks_Mode_Behavior" } ) }}</p>
Revert to this revision