quirks mode

Quirks Mode defines quirks in CSS and Selectors that are necessary to support for Web browsers for compatibility with the Web. Browsers have several rendering modes to render HTML documents. The reason for this is basically a historical accident. The CSS specification was incompatible with the behavior of existing browsers which existing Web content relied on. In order to comply with the specification while not breaking existing content, browsers introduced a new rendering mode (no-quirks mode). Some browsers still had the shrink-wrapping behavior for images in table cells in their no-quirks mode, and sites started relying on that, so browsers that implemented the specification’s behavior introduced a third mode (limited-quirks mode). In hindsight, it would have been better to make the default CSS behavior be compatible with what the existing content relied on and providing opt-ins to different behavior. The different modes have since gained a few differences outside of CSS. For example, Gecko has removed a quirk about list item bullet size , and Chromium has removed a quirk where display was forced to table or inline-table on table elements . For example, Gecko aligned their implementation of the :active and :hover quirk with this specification and thereby achieved closer interoperability with other browsers. Where possible, limit quirks to a fixed set of legacy features so they don’t propagate into new features. For example, § 3.1 The hashless hex color quirk is limited to a fixed set of CSS properties so that the quirk does not apply in SVG features that also accept colors, or in CSS gradients where the grammar could otherwise become ambiguous . This specification does not enumerate all quirks that currently exist in browsers. A number of quirks are specified in HTML, DOM, CSSOM and CSSOM View. [[HTML]]( "HTML Standard") [[DOM]]( "DOM Standard") [[CSSOM]]( "CSS Object Model (CSSOM)") [[CSSOM-VIEW]]( "CSSOM View Module") If a quirk is not specified anywhere, it is probably due to the second bullet point above. All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this specification are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [[RFC2119]]( "Key words for use in RFCs to Indicate Requirement Levels") The document’s body element is different from HTML’s the body element , since the latter can be a frameset element. In quirks mode and limited-quirks mode , for a block container element whose content is composed of inline-level elements, the element’s line-height must be ignored for the purpose of calculating the minimal height of line boxes within the element. It is at the time of writing undefined how percentage heights inside tables work in CSS. This specification does not try to specify what to use as the containing block for calculating percentage heights in tables. Godspeed! ...then element must have its border box size in the block flow direction set using the following algorithm: 2. Let size be the size of the initial containing block in the block flow direction minus margins. 3. Return the bigger value of size and the normal border box size the element would have according to the CSS specification. ...then body must have its border box size in the block flow direction set using the following algorithm: 2. Let size be the size of body’s parent element’s content box in the block flow direction minus margins. 3. Return the bigger value of size and the normal border box size the element would have according to the CSS specification. What should happen if the html and the body have different writing modes? In quirks mode , for the purpose of ca

We are committed to providing a friendly, safe, and welcoming environment for all. Please read and respect the Code of Conduct. Folks notice minor and larger issues with the Quirks Mode Standard all the time and we'd love your help fixing those. Pull requests for typographical and grammar errors are also most welcome. Issues labeled "good first issue" are a good place to get a taste for editing the Quirks Mode Standard. Note that we don't assign issues and there's no reason to ask for availability either, just provide a pull request. If you are thinking of suggesting a new feature, read through the FAQ and Working Mode documents to get yourself familiarized with the process. In short, change quirks.bs and submit your patch, with a good commit message. Please add your name to the Acknowledgments section in your first pull request, even for trivial fixes. The names are sorted lexicographically. To ensure your patch meets all the necessary requirements, please also see the Contributor Guidelines. Editors of the Quirks Mode Standard are expected to follow the Maintainer Guidelines. A dashboard showing the tests running against browser engines can be seen at wpt.fyi/results/quirks. For quick local iteration, run make ; this will use a web service to build the standard, so that you don't have to install anything. See more in the Contributor Guidelines.