Compare Revisions

Mozilla Quirks Mode Behavior

Change Revisions

Revision 50233:

Revision 50233 by DBaron on

Revision 50234:

Revision 50234 by Gbyxwc on

Mozilla Quirks Mode Behavior
Mozilla Quirks Mode Behavior
"Web Development"
"Web Development"

Revision 50233
Revision 50234
n7    <p>n
8      The following is a <i>rough</i> list of the differences tha
>t exist between Mozilla's standards mode and quirks mode behavior 
>. This list is current as of early June 2001. Since that time the 
> most significant change has been that many of the form control-r 
>elated quirks have been removed. Another often-noticed change is  
>that, in standards mode, we reject CSS stylesheets that have a MI 
>ME type other than <code>text/css</code>. 
9    </p>
10    <ul>
11      <li>Miscellaneous &amp; Style
12        <ul>
13          <li>All of the style rules in {{template.Source("layout
>/style/quirk.css")}} apply. 
14          </li>
15          <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>. 
16          </li>
17          <li>The CSS parser accepts colors not beginning with #.
18          </li>
19          <li>The CSS parser interprets unitless numbers as <code
>>px</code> (except for <code>font-size</code> because that was wh 
>at Nav4 did, and except for <code>line-height</code> and any othe 
>r properties where they have distinct meaning). 
20          </li>
21          <li>HTML colors are parsed differently (# is not requir
>ed, and missing digits are filled in differently) 
22          </li>
23          <li>An empty string for the <code>background</code> att
>ribute sets the background URL to empty only in quirks mode. 
24          </li>
25          <li>System fonts work differently in navquirks mode (sh
>ouldn't the form controls that use them be the ones working diffe 
>rently instead?). 
26          </li>
27          <li>HTML (1-7) and CSS (<code>xx-small</code> - <code>x
>x-large</code>) font sizes are calculated slightly differently (s 
>ee {{template.Bug(18136)}}). 
28          </li>
29          <li>List bullets do not inherit the font size of the li
>st in quirks mode. 
30          </li>
31          <li>The <code>:hover</code> pseudoclass will only be ap
>plied to links, images, and form controls, unless the selector in 
>cludes tag names, ids, or attributes. 
32          </li>
33        </ul>
34      </li>
35    </ul>
36    <ul>
37      <li>Block and Inline layout
38        <ul>
39          <li>
40            <b>{{mediawiki.external('This quirk is present in alm
>ost standards mode.')}}</b> Line height (not <code>line-height</c 
>ode>) calculations are different to fix {{template.Bug(5821)}} an 
>d {{template.Bug(24186)}} (some other issues are described in {{t 
41          </li>
42          <li>There are a bunch of quirks to get percentage heigh
>ts on images, tables, objects, and applets (etc.?) to "work" (the 
> way they did in Nav4), even though CSS says that percentage heig 
>hts should behave like 'auto' heights when the parent element doe 
>sn't have a fixed height. See {{template.Bug("33443#c9")}} a desc 
>ription]. See also {{template.Bug(41656)}} and its duplicates. So 
>me of these quirks may cause other effects (see {{template.Bug(54 
43          </li>
44          <li>The <code>HR</code> element is treated differently 
>in quirks and strict mode (and arguably wrong in both). 
45          </li>
46        </ul>
47      </li>
48    </ul>
49    <ul>
50      <li>Tables
51        <ul>
52          <li>Table background colors work differently (see {{tem
>plate.Bug(4510)}}) It is not clear that this quirk is needed. 
53          </li>
54          <li>In quirks mode <code>absmiddle</code> (handled inco
>rrectly?) 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< 
55          </li>
56          <li>
57            <code>TD</code>, <code>TH</code>, <code>TR</code>, <c
>ode>THEAD</code>, <code>TBODY</code>, and <code>TFOOT</code> elem 
>ents have the document background (and color?) applied to them (w 
>hen the document background is specified in certain ways?) (see a 
>lso {{template.Bug(70831)}} ). 
58          </li>
59          <li>The <code>empty-cells</code> property defaults to <
>code>hide</code> in quirks mode but show (according to CSS2 errat 
>a) in strict mode (see {{template.Bug(33244)}}) (though the corre 
>ct fix would be to specify it on the HTML <code>TABLE</code> elem 
>ent in <code>quirk.css</code>). 
60          </li>
61          <li>In quirks mode floated tables never move to the nex
>t "line" if they don't fit next to other floats, they just keep w 
>idening the page (see {{template.Bug(43086)}}). 
62          </li>
63          <li>In quirks mode <code>colspan="0"</code> and <code>r
>owspan="0"</code> are intentionally not handled as described in H 
64          </li>
65          <li>
66            <code>hspace</code> and <code>vspace</code> are suppo
>rted on <code>TABLE</code> only in quirks mode. 
67          </li>
68          <li>In quirks mode, when tables have a border style of 
><code>inset</code> or <code>outset</code>, the border color is ba 
>sed on the background color of the table or of the nearest ancest 
>or with non-transparent background. 
69          </li>
70          <li>In quirks mode table cells with a border have a min
>imum width of one pixel. 
71          </li>
72          <li>The basic table layout strategy ignores padding (on
> what) in quirks mode. 
73          </li>
74          <li>The basic table layout strategy handles widths diff
>erently in some way. 
75          </li>
76        </ul>
77      </li>
78    </ul>
79    <ul>
80      <li>Forms
81        <ul>
82          <li>Button inputs calculate their size differently.
83          </li>
84          <li>In standard mode a <code>BUTTON</code> element (?) 
>can submit only if it lacks a <code>type</code> attribute. 
85          </li>
86          <li>Text inputs (and other form controls containing tex
>t???) calculate their size differently (see {{template.Bug("X")}} 
> for the description of the original fix and also {{template.Bug( 
>"X")}} for suggested modifications) 
87          </li>
88          <li>The fonts for button <code>INPUT</code> elements an
>d <code>SELECT</code> elements are computed differently. 
89          </li>
90          <li>The requirement of HTML that one button in a radio 
>group is always selected (by default) is not enforced in quirks m 
91          </li>
92        </ul>
93      </li>
94    </ul>
95    <ul>
96      <li>Frames
97        <ul>
98          <li>In quirks mode <code>marginwidth</code> and <code>m
>arginheight</code> on a <code>FRAME</code> are propagated to the  
>contained <code>BODY</code>. 
99          </li>
100          <li>In a frame size specification <code>0*</code> is tr
>eated as <code>1*</code> (see {{template.Bug(40383)}}). 
101          </li>
102          <li>The <code>scrolling</code> attribute on <code>FRAME
></code> is handled differently. 
103          </li>
104        </ul>
105      </li>
106    </ul>
107    <ul>
108      <li>HTML Parser
109        <ul>
110          <li>In quirks mode, we parse HTML comments in a way com
>patible with older browsers instead of treating "--" as the comme 
>nt start and end delimeter 
111          </li>
112        </ul>
113      </li>
114    </ul>
115    <div class="originaldocinfo">
116      <h3 name="Original_Document_Information">
117        Original Document Information
118      </h3>
119      <ul>
120        <li>Author(s): David Baron, Boris Zbarsky
121        </li>
122        <li>Last Updated Date: July 8, 2003
123        </li>
124      </ul>
125    </div>
tt13    <div id="wyikol" style="overflow:auto; height: 1px;">
14      <a class="external" href="">56564
15    </div>

Back to History