The DOCTYPE mode selection mechanism of well-known browsers

Document Scope

This article covers mode switching for Firefox and other Gecko-based browsers, Safari, Chrome and other Webkit-based browsers, Opera, Konqueror, Internet Explorer for Mac, Internet Explorer for Windows, and the embedded IE browser. Avoid mentioning the browser engine's name, and instead mention the name of the most well-known browser using that engine.

This article focuses on the mechanism of mode selection rather than documenting the exact behavior of each mode.

model

The different modes are:

Mode with content type text/html

The mode selection for text/html content is based on doctype sniffing (discussed later in this article). In IE8, the mode also depends on other factors. However, by default in IE8, the mode for non-intranet sites that are not on the Microsoft-provided blacklist depends on the document type.

It cannot be overstated that the exact behavior of modes varies from browser to browser, even though this article discusses them uniformly.

Quirks Mode

In quirks mode, browsers violate modern web formatting conventions in order to avoid "breaking" pages that were authored according to practices that were popular in the late 1990s. Different browsers implement different quirks in their behavior. In Internet Explorer 6, 7, and 8, quirks mode is effectively frozen in IE 5.5. In other browsers, quirks mode is a small deviation from standards mode.

If you are creating new pages, you should conform to the relevant specifications (especially CSS 2.1) and use standards mode.

Standards Mode

In standards mode, the browser attempts to give standards-conforming documents specification-correct processing to the extent possible in a given browser.

Different browsers follow different stages, so standards mode is not a single goal.

HTML5 calls this mode "no quirks mode"

Almost Standards Mode

Safari, Chrome, Opera (starting from 7.5) and IE8 also have a mode called "quasi-standards mode" which implements the vertical size of table cells according to traditional practices rather than strictly following the CSS2 specification. Mac IE5, Windows IE6 and 7, Opera prior to 7.5, and Konqueror do not require near-standards mode because they do not strictly follow the CSS2 specification for vertical table cell sizing, at least in their respective standards modes. In fact, their standards mode is closer to Mozilla's semi-standards mode than to Mozilla's standards mode.

HTML5 calls this mode "limited quirks mode".

IE7 Mode

IE8 has a mode that essentially freezes a copy of IE7's standards mode. Other browsers don't have a mode like this, and it's not specified by HTML5.

Mode with content type application/xhtml+xml (XML mode)

In Firefox, Safari, Chrome and Opera, the application/xhtml+xml HTTP content type (not the meta element nor the doctype!) triggers XML mode. In XML mode, browsers attempt to give XML documents specification-correct processing to the extent possible in a given browser.

IE6, 7, and 8 do not support application/xhtml+xml, nor does Mac IE5.

In the WebKit-based Nokia S60 browser, the application/xhtml+xml HTTP content type does not trigger XML mode because the focus in mobile walled gardens is compatibility with non-standard content. (Older "mobile browsers" can't use a true XML parser because the non-standard content is marked as XML.)

Without having fully tested Konqueror, I can't say exactly what will happen in this browser.

Non-Web Modes

Some engines have modes that have nothing to do with web content. They are only mentioned here for the sake of completeness. Opera has a WML2.0 mode. WebKit on Leopard has a special mode for legacy Dashboard widgets.

Influence

Here are the main impacts of these modes:

layout

The text/html mode mainly affects CSS layout. For example, it's a quirk that tables don't inherit styles. In some browsers' quirks mode, the box model becomes the IE5.5 box model. This document does not enumerate all layout quirks.

In semi-standards mode (in browsers that have such a mode), the height of table cells that only contain images is different from that in standards mode.

In XML Schema, selectors have different case sensitivity behaviors. Additionally, specific rules for the HTML body element will not apply to older browsers that have not implemented the latest CSS 2.1 changes.

Analysis

There are also some quirks that affect the parsing of HTML and CSS and can cause standards-compliant web pages to be parsed incorrectly. The quirks layout determines whether these quirks are turned on or off. Regardless, it’s important to understand the main similarities and differences between quirks mode and standards mode in terms of CSS layout and parsing (not HTML parsing).

Some people mistakenly refer to standards mode as "strict parsing mode", which misleads the browser into enforcing HTML syntax rules and evaluating markup for correctness. This is not the case. Even when standards mode layout is in effect, browsers still do tag soup (http://en.wikipedia.org/wiki/Tag_soup) correction work. (Before the release of Netscape 6 in 2000, Mozilla did have parsing modes for enforcing HTML syntax rules. These modes were deprecated as incompatible with existing Web content.)

Another common misunderstanding is about XHTML parsing. It is generally believed that using the XHTML doctype results in different parsing. In fact, this is not the case. XHTML documents with content type text/html use the same parser as HTML documents. Currently browsers care that XHTML with a doctype of text/html is just "tag soup with croutons" (with extra slashes here and there).

Only documents using the XML document type (for example: application/xhtml+xml or xmapplication/) will trigger XML mode for parsing, and the parser at this time is completely different from the HTML parser.

script

While quirks mode is mostly about CSS, there are some things about scripting as well. For example, in Firefox quirks mode, HTML id attributes establish object references in the global script scope just as they do in IE. The impact of scripting in IE8 is more noteworthy than in other browsers.

In XML mode, some DOM APIs behave completely differently because the DOM API behavior for XML was defined to be incompatible with the behavior for HTML.

Doctype sniffing (also called doctype conversion)

Modern browsers use doctype sniffing to determine the engine mode for text/html documents. This means that the choice of mode is based on the document type declaration (or lack thereof) at the beginning of the HTML document. (This does not apply to documents using the XML document type.)

The document type declaration (doctype) is a syntactical forgery of SGML, the old markup framework that HTML before HTML5 was defined in terms of. In the HTML4.01 specification, the document type declaration describes the version information of HTML. Despite the name "document type declaration" and despite what the HTML 4.01 specification describes as "version information", the document type declaration is not intended to classify an SGML or XML document as a particular type of document, even if it appears to be one (because of the name). (More in the appendix)

Neither the HTML 4.01 specification nor ISO 8879 (SGML) say anything about using document type declarations as engine mode switches. Doctype sniffing is based on the observation that, when doctype sniffing was designed, the vast majority of quirks documents had neither a document type declaration nor a reference to an old DTD. HTML5 accepts this fact and defines the text/html doctype as the only mode switch.

A typical pre-HTML5 document type declaration contains (separated by whitespace) the "<!DOCTYPE" string, the universal identifier of the root element ("html"), the "PUBLIC" string, the public identifier of the DTD in quotes, a possible system identifier (URL) of the same DTD, and the character ">". The document type declaration is placed before the document's root element start tag.

Select doctype

text/html

Here is a simple guide on how to choose a doctype when creating a new text/html document:

Standard mode, cutting-edge verification

<!DOCTYPE html>

This is the right thing to do if you want to validate new features like <video> , <canvas> , and ARIA. Note that the HTML5 valid definition is still in flux, so be sure to test image alignment in Firefox, Safari, Chrome, Opera 9, or Opera 10. It is not sufficient to test image alignment in Internet Explorer, make sure you test it in IE8 as well.

Standard mode, a more stable verification target

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

This doctype also triggers standards mode, and the 10-year-old HTML 4.01 valid definition is stable. Be sure to test image alignment in Firefox, Safari, Chrome, Opera 9, or Opera 10. It is not sufficient to test image alignment in Internet Explorer, make sure you test it in IE8 as well.

You want to use standards mode, but still want to verify deprecated markup or use sliced ​​images in table layouts and don't want to fix them.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

This triggers near-standards mode (and the old Mozilla full Standards mode). Note that layouts based on sliced ​​images implemented with tables may break if ported to HTML5 later (this also applies to full standards mode).

Intentionally using quirks mode

No doctype.

Please don't do this. Designing for quirks mode intentionally will haunt you in the future when your colleagues or successors won't even care about Windows IE6 (no one cared about Netscape 4.x and IE5 anymore). Designing for quirks mode is a bad idea. Believe me.

If you want to still support Windows IE6, it's better to make a special hack for it using conditional comments than to make other browsers fall back to quirks mode.

I don't recommend any XHTML doctype, because XHTML used as text/html is considered harmful. Regardless, if you choose to use the XHTML doctype, be aware that the XML declaration will cause IE6 (but not IE7!) to trigger quirks mode.

application/xhtml+xml

A simple guideline for application/xhtml+xml is to never use doctype. The web pages in this mode are not "strictly conforming" to XHTML1.0, but this is not important. (Please see the appendix below)

IE8 Complications

A List Apart once introduced that in addition to doctype, IE8 will use mode transitions based on meta elements as one of the factors for mode selection. (See comments by Ian Hickson, David Baron, David Baron again, Robert O'Callahan and Maciej Stachowiak.)

IE8 has 4 modes: IE5.5 quirks mode, IE7 standards mode, IE8 semi-standards mode and IE8 standards mode. The mode chosen is based on data from several sources: doctype, meta elements, HTTP headers, periodically downloaded data from Microsoft, the LAN domain, settings made by the user, settings made by the LAN administrator, the mode of the parent frame (if any), and whether the address bar Compatibility View button is triggered by the user. (For other applications that embed the engine, the mode also depends on the embedding application.)

Fortunately, IE8 will mostly use doctype sniffing like other browsers if the following conditions are met:

• The author did not set the X-UA-Compatible HTTP header
• The author did not set the X-UA-Compatible meta tag
• Microsoft has not placed the site's domain name on a blacklist
• The LAN administrator has not placed the site on the blacklist
• The user has not pressed the Compatibility View button (or has otherwise been added to a specific user blacklist)
• The site is not in the local area network domain
• User did not choose to show all sites in IE7
• The page is not embedded in a compatible mode page via a frame

IE8 performs doctype sniffing just like IE7, except for the two cases mentioned above regarding X-UA-Compatible. IE7 emulation is called Compatibility View.

In the X-UA-Compatible case, IE8 behaves completely differently from other browsers. Want to see the appendix to this page or the flowchart in PDF and PNG formats?

Unfortunately, without the X-UA-Compatible HTTP header or meta tag, IE8 lets users inadvertently downgrade pages from IE8 standards mode to IE7 mode, which is an emulated IE7 standards mode, even when using the appropriate doctype. Worse still, LAN administrators can do the same. Microsoft can also blacklist all the domains you use.

To counter these effects, doctype is not enough, you need the X-UA-Compatible HTTP header and meta tag.

The following is a simple guide for selecting the X-UA-Compatible HTTP header or meta tag for new text/html documents that already have a doctype that triggers standards mode or near-standards mode in other browsers:

Your domain is not on Microsoft's blacklist, and you are more concerned with not having browser-specific annoyances than ensuring users can't fall back to IE7 behavior.

You do not need to include the X-UA-Compatible HTTP header or meta tag.

Your domain is on Microsoft's blacklist because other authors on your domain have broken sites that may have caused users to enable Compatibility View for the entire domain. You are worried about Google or Digg framing your site or you want to ensure that users cannot use Compatibility View.

First, include the following meta element in your page (it is illegal in HTML5) <meta http-equiv="X-UA-Compatible" content="IE=Edge"> (before any script elements), or set the following HTTP header: X-UA-Compatible: IE=Edge

Your site works in IE7 but breaks in IE8

First, include the following meta element in your page (it is illegal in HTML5): (before any script elements), or set the following HTTP header: X-UA-Compatible: IE=EmulateIE7, then fix your site to not rely on non-standard IE7 behavior and migrate to IE=Edge.

Related links

• Eric Meyer writes about Mac IE5 mode in Using the Correct Doctype
• Mozilla's Doctype Sniffing by David Baron
• Lance Silver discusses modes and doctype sniffing in Windows IE6 in CSS Enhancements in IE6.
• Opera9 doctype conversion
• Faruk Ateş's solution for IE8 and X-UA-Compatible

Addendum: A Plea to XML Implementors and Specification Authors

Please don't bring doctype sniffing to XML.

Doctype sniffing is a tag-soup solution to a tag-soup problem. Doctype sniffing is a heuristic designed after the HTML4 and CSS2 specifications were published to distinguish outdated documents from documents that conform to the behavior their authors might expect.

Occasionally people have suggested using doctype sniffing on XML to schedule different processing, identify the vocabulary in use, or activate features. This is a bad idea. Dispatching and vocabulary identification should be namespace-based, while feature activation should be based on explicit processing instructions or elements.

The whole idea of ​​well-formedness was introduced to allow DTD-less parsing of XML, and to promote doctype-less documents. In the formal case, if two XML documents have the same canonical form and an application processes them differently (and the difference is not due to a lack of choice in processing external entities), the application may be broken. In practice, if two XML documents result in the same content being reported (qnames ignored) to a SAX2 content processor and an application processes the documents differently, the application is probably broken. Given that as a Web author you cannot trust everyone to parse their pages with an XMLprocessor that resolves extra entities (even if some browsers appear to do so because they map certain common identifiers to a truncated DTD defining the entities), inserting a doctype into XML for the Web is pointless and usually leads to cargo cultish habits. (You can still validate against a DTD using the W3C validator's DTD override feature, although the W3C validator will say the result is only provisionally valid. Or better yet, you can use relaxed NG validation, which doesn't pollute the document with schema references.) Requiring doctype for the purpose of sniffing is pretty silly, even if that's the way to go in HTML practice.

Furthermore, when a low-level specification defines two things as equal, a high-level specification should not try to give them different meanings. Consider <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> . If the public identifier is removed, the same DTD is still specified, so the doctype <!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> means the same as the previous doctype. Should they be sniffed differently? The theory can be further developed. Suppose example.com is given a DTD called foobar.dtd: <!DOCTYPE html SYSTEM "http://example.com/foobar.dtd"> . How to sniff this? It should mean the same thing. Even the entire DTD can be pasted into the document.

In other words, if you have #include "foo.h", you shouldn't have any black magic binding to the name foo.h, because it should be possible to copy the contents of foo.h into the document or copy foo.h into bar.h and say #include "bar.h".

The reason I'm not worried about HTML and SGML constructing the same parameters is that web browsers won't use a real SGML parser to parse HTML, so I think there's no point in pretending to be SGML. Anyway, if you're still not convinced, read W. Eliot Kimber's article on the matter comp.text.sgml

Appendix: How to handle some doctypes in text/html

In the following table, quirks mode, standards mode, and semi-standard are denoted as Q, S, and A, respectively. When the browser has only two modes, standards mode is marked as "S" if the table cell row height behaves the same as Mozilla's standards mode, and "A" if the table cell row height behaves the same as Mozilla's semi-standards mode.

Note that XHTML served using the XML content model is rendered in XML mode.

The purpose of this table is not to say that all doctypes in the table are reasonable choices for new pages. The purpose of this table is to show what data I base my recommendations on.

The following abbreviations are used for column headings:

NS6

Mozilla 0.6…0.9.4 and Netscape 6.0…6.2.3

Old Moz

Mozilla 0.9.5 to 1.1 alpha and Mozilla 1.0

Moz & Safari & Opera 10 & HTML5

Mozilla 1.0.1, Mozilla 1.1 beta and later, Firefox through Netscape 7, Safari 0.9 through Safari 4.0 beta, Opera 10, Chrome, Konqueror 3.5, HTML5-specific behavior

Opera 9.0

Opera 9.0…9.20

IE 8 & Opera 9.5

Default IE8 without X-UA-Compatible and compatibility mode overrides ("A" in this case means IE8 near-standards mode), Opera 7.5…8.54 and 9.5…9.6

IE 7 & Opera 7.10

IE7, IE8 in compatibility mode without X-UA-Compatible override (in this case "A" means IE7 mode), and Opera 7.10…7.23

IE 6 & Opera 7.0

Windows IE 6 and Opera 7.0…7.03

Mac IE 5

Mac IE 5.0…5.2.3

Konq 3.2

Konqueror 3.2.2…3.3 (and possibly 3.1…3.2.1; I haven't confirmed yet)

History

Moziila's doctype sniffing code was significantly modified in October 2000, September 2001, and June 2002. This document describes the state of the Mozilla (and Netscape 6.x) builds available at ftp.mozilla.org as of 2000.10.19. This document does not cover how doctype sniffing works in Mozilla M18 (and Netscape 6.0 PR3). Safari's doctype sniffing code has also been significantly modified since the first public beta. This document does not cover behavior earlier than version V73 also known as 0.9.

The doctype sniffing code in Konqueror prior to 3.5 seems to have come from a very old version of Safari. Konqueror now matches Safari, with doctype sniffing code from Mozilla.

As can be seen from the table, Opera's doctype sniffing is changing from being more IE-like to being more Mozilla-like, although Opera 9.5 and 9.6 are on the way back. At the same time, the layout behavior of Opera's quirks mode has been switched from emulating IE6's quirks mode to Mozilla's quirks mode.

Appendix: IE8 mode selection

Get started: Go to “X-UA-Compatible meta?”

X-UA-Compatible meta?

IE=7: Use IE7 standards

IE=EmulateIE7: Enter "Quirks or no doctype? (Compatibility mode)"

IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or no or script appears first: Enter "X-UA-Compatible HTTP header?"

IE=8 or IE=Edge or IE=99 or IE=9.9: Enter "Near-Standards Mode?"

IE=5: Use quirks mode (IE5.5)

X-UA-Compatible HTTP header?

IE=7: Use IE7 standards mode

IE=EmulateIE7: Go to "Quirks or no doctype? (Compatibility mode)"

IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or None: Go to "Show all sites...preset?"

IE=8 or IE=Edge or IE=99 or IE=9.9: Enter "Near-Standards Mode?"

IE=5: Use quirks mode (IE5.5)

Quirks mode or no doctype? (Compatibility mode)

Yes: Use quirks mode (IE5.5)

No: Use IE7 Standards Mode

Show all sites...preset?

Yes: Enter "Quirks mode or no doctype? (Compatibility mode)"

No: Go to "Show LAN sites...preset?"

Show LAN sites...preset?

Yes: Go to "Is the site located in a LAN domain?"

No: Go to "Is the domain name on a list maintained by Microsoft?"

Is the domain on a list maintained by Microsoft?

Yes: Enter "Quirks mode or no doctype? (Compatibility mode)"

No: Go to "Embedded by a compatible mode page using a frame?"

Embedded by a compatible mode page using a Frame?

Yes: Enter "Quirks mode or no doctype? (Compatibility mode)"

No: Go to "Compatibility Mode Button Pressed?"

Compatibility Mode button pressed?

Yes: Enter "Quirks mode or no doctype? (Compatibility mode)"

No: Enter "Quirks mode or no doctype? (IE8)"

Quirks mode or no doctype? (IE8)

Yes: Enter "Use Quirks Mode (IE5.5)"

No: Enter "quasi-standard mode?"

A quasi-standard model?

Yes: Use IE8 semi-standards mode

No: Use IE8 Standards Mode

These steps are available as flowcharts in PDF and PNG formats.

Acknowledgements

Thanks to Simon Pieters, Simon Pieters and Anne van Kesteren for helping me correct the mode tables for various Opera versions and for their comments. Thanks to Simon Pieters for another IE8 flowchart.