The selection mechanism of DOCTYPE mode by well-known browsers

Document scope

The mode switching included in this article is suitable 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 browsers with built-in IE. Avoid mentioning the name of the browser engine and instead use the name of the most well-known browser of the engine.

This article focuses on the selection mechanism of patterns rather than recording the exact behavior of each pattern.

model

Here are a variety of different modes:

The pattern with content type text/html

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

It is not an exaggeration to emphasize the difference in the precise behavior of patterns in each browser, even if there is a unified discussion in this article.

Quirks Mode

In the quirk mode, in order to avoid destroying pages created based on practices popular in the late 1990s, browsers violate modern web format specifications. Different browsers implement different quirk behaviors. In Internet Explorer 6, 7 and 8, the quirk pattern is effectively frozen in IE5.5. In other browsers, quirk mode is a small amount of offsets that align with the standard mode.

If you are creating a new web page, you should comply with relevant specifications (especially CSS2.1) and use the standard mode.

Standards Mode

In standard mode, the browser tries to properly handle the specifications in the specified browser by giving the standard-compliant documents to the extent that it is standardized.

Different browsers follow different stages, so the standard mode is not a single goal either.

HTML5 calls this mode no quirks mode

Almost Standards Mode

irefox, Safari, Chrome, Opera (starting from 7.5) and IE8 also have a mode called quasi-standard mode, which implements the vertical dimensions of table cells in accordance with traditional practices rather than strictly complying with the CSS2 specification. Mac IE5, Windows IE6 and 7, Opera 7.5 previous versions and Konqueror do not require quasi-standard mode because they do not strictly follow the CSS2 specification in their respective standard modes to achieve vertical dimensions of table cells. In fact, their standard mode is closer to Mozilla's quasi-standard mode than Mozilla's standard mode.

HTML5 calls this mode limited quirks mode.

IE7 mode

There is a mode in IE8 that mainly freezes the copy of the IE7 standard mode. Other browsers do not have a pattern like this, and this pattern is not specified by HTML5.

Schema with content type application/xhtml+xml (XML pattern)

In Firefox, Safari, Chrome, and Opera, the application/xhtml+xml HTTP content type (not a meta element or doctype!) will trigger the XML pattern. In XML pattern, the browser tries to give XML documents the correct specifications to the extent that it is in the browser.

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

In the WebKit-based Nokia S60 browser, the application/xhtml+xml HTTP content type cannot trigger the XML schema because the focus in mobile walled gardens is compatibility with irregular content. (Old-style mobile browsers cannot use real XML parsers because the non-standard content has been marked XML.)

Since Konqueror is not fully tested, I can't say exactly what will happen in this browser.

Non-Web Modes

The patterns that some engines have have nothing to do with web content. For completeness, they are mentioned here only. Opera has a WML2.0 mode. WebKit on Leopard has a specific mode for legacy Dashboard widgets.

Influence

Here are the main effects of these patterns:

layout

The text/html pattern mainly affects the CSS layout. For example, it is a quirk for tables not to inherit styles. In some browsers' quirk mode, the box model becomes the box model of IE5.5. This document does not list all layout quirks.

Quasi-standard mode (in browsers with this mode), only table cells containing pictures differ in high and standard mode.

In XML schema, selectors have different case-sensitive behaviors. Additionally, unique rules for HTML body elements cannot be applied to older browsers that do not implement the latest CSS2.1 changes.

Analysis

There are also some quirks that affect HTML and CSS parsing and will cause web pages that meet standards to be parsed incorrectly. The layout of quirks determines whether these quirks are turned on. In any case, it is very important to understand the main similarities and differences of quirk patterns and standard patterns in CSS layout and parsing (non-HTML parsing).

Some people mistakenly call the standard mode strict parsing mode, which makes people misunderstand the browser's enforce HTML syntax rules and the browser's evaluation of the correctness of tags. This is not the case. Even when the standard mode layout takes effect, the browser will still make tag soup (tag soup, http://en.wikipedia.org/wiki/Tag_soup) correction work. (Before Netscape6 was released in 2000, Mozilla did have parsing patterns for enforcing HTML syntax rules. These patterns were abandoned incompatible with existing web content.)

Another common misconception is about XHTML parsing. It is usually believed that different parses are obtained using XHTML doctype. In fact, this is not the case. The content type is the same as the parser and HTML document used in the XHTML document of text/html. What browsers care about right now is that XHTML with document type text/html is just a tag soup with crouts (extra slashes everywhere).

Only when an XML document type document (for example: application/xhtml+xml or xmapplication/) is used, the parser will trigger the XML schema for parsing. The parser at this time is completely different from the HTML parser.

script

While the quirk pattern is mainly about CSS, some are about scripting. For example, in Firefox's quirk pattern, the HTML id attribute establishes object references to the global script scope just like in IE. The impact of scripts in IE8 is more worthy of attention than other browsers.

In the XML schema, some DOM APIs behave completely differently because the DOM API behavior of XML is not compatible with HTML behavior when defined.

doctype sniffing (also called doctype conversion)

Modern browsers use doctype sniffing to determine the engine mode of text/html documents. This means that the choice of schema is based on the document type declaration (or missing) starting with the HTML document. (This is not suitable for documents using XML document type.)

Document type declaration (doctype) is a syntax forgery of SGML. SGML is an old-style markup framework. HTML before HTML5 is defined based on it. In the HTML4.01 specification, the document type declaration describes the version information of HTML. Although the name is a Document Type Declaration and the HTML 4.01 specification describes version information, document type declarations do not apply to classify SGML or XML documents as specific types of documents, even if it looks like (because of the name). (More content is in the appendix)

Neither the HTML4.01 specification nor ISO 8879 (SGML) says anything about using document type declarations as engine mode conversion. Doctype sniffing is based on observation. When doctype sniffing is designed, most quirks do not have document type declarations or references to old DTDs. HTML5 accepts this fact and defines doctype as the only mode conversion in text/html.

A typical pre-HTML5 (pre-HTML5) document type declaration contains (separated by blanks) <!DOCTYPE string, a common identifier for the root element (html), a PUBLIC string, a DTD common identifier in quotes, a possible system identifier (URL) and a character for the same DTD. The document type declaration is before the document's root element starts the label.

Select doctype

text/html

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

Standard model, cutting-edge verification

<!DOCTYPE html>

If you want to verify new features such as <video>, <canvas>, and ARIA, then this is correct. Note that the effective definition of HTML5 is still changing, make sure to test image alignment in Firefox, Safari, Chrome, Opera9, or Opera10. It is not enough to test image alignment in Internet Explorer, make sure you have also tested in IE8 anyway.

Standard mode, more stable verification target

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

This doctype will also trigger the standard mode, and the effective definition of HTML4.01 for 10 years old is stable. Make sure to test image alignment in Firefox, Safari, Chrome, Opera9, or Opera10. It is not enough to test image alignment in Internet Explorer, make sure you have also tested in IE8 anyway.

To use standard mode, but still verify that markings are not recommended or using 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>

It triggers quasi-standard mode (and full Standards mode in the old-fashioned Mozilla). Note that if later ported to HTML5, the layout based on sliced ​​images implemented with tables may be broken (and so does the full standard pattern).

To use quirk mode on purpose

No doctype.

Please don't do this. Designs intentionally made for quirk mode will bother you, and in the future no one cares about Windows IE6 (Netscape 4.x and IE5 are no longer concerned). Designing for quirk patterns is a bad idea. Believe me.

If you want to still support Windows IE6, it is better to make a special hack conditional comment on it than to regress other browsers to quirk mode.

I do not recommend any XHTML doctype, as XHTML is considered harmful to use as text/html. Anyway, if you choose to use XHTML doctype, note that the XML declaration causes IE6 (but not IE7!) to trigger the quirk pattern.

application/xhtml+xml

A simple guide to application/xhtml+xml is never to use doctype. The web pages under this method are not strictly consistent with XHMTL1.0, but this does not matter. (Please see the appendix below)

IE8 Complications

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

There are 4 modes for IE8: IE5.5 Quirk Mode, IE7 Standard Mode, IE8 Qual-Standard Mode and IE8 Standard Mode. The selection of mode depends on data from several aspects: doctype, meta elements, HTTP headers, regular download data from Microsoft, LAN domains, settings made by users, settings made by LAN administrators, modes of the parent framework (if any) and address bar compatible view button are triggered by users. (For other applications embedded in the engine, the pattern also depends on the embedded application.)

Fortunately, IE8 will generally use doctype sniffing like other browsers if the following occurs:

• The author does not set the X-UA-Compatible HTTP header
• The author does not set the X-UA-Compatible meta tag
• Microsoft does not place the domain name of the site on the blacklist
• The LAN administrator did not place the site on the blacklist
• The user does not press the Compatibility View button (or otherwise added to a specific user blacklist)
• This site is not in the LAN domain
• User has no choice to display all sites in IE7
• The page is not embedded in the compatible mode page through frame

Except for the two cases regarding X-UA-Compatible, IE8 performs doctype sniffing like IE7. IE7 emulation (IE7 emulation) is called compatible view.

In the case of X-UA-Compatible, IE8 behaves completely differently than other browsers. I would like to see the appendix or flowchart in PDF and PNG formats on this page.

Unfortunately, there is no HTTP header or meta tag for X-UA-Compatible, and even with the appropriate doctype, IE8 allows users to accidentally reduce the page from IE8's standard mode to IE7 mode, which is a simulated IE7 standard mode. Worse, LAN administrators can do the same. Microsoft can also blacklist all domain names you use.

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

The following simple guide is for new text/html documents that already have doctype trigger standard mode or quasi-standard mode in other browsers for how to choose X-UA-Compatible HTTP header or meta tag:

Your domain is not on Microsoft's blacklist, and you're more concerned with no browser-specific annoying stuff than ensuring that users can't fall back to present IE7 behavior.

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

Your domain is on Microsoft's blacklist, because other authors in your domain destroy the site or causing users to enable compatible views for the entire domain, you are worried that Google or Digg will embed your site with frame or you want to make sure that users cannot use compatible views.

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

Your site works in IE7 but breaks in IE8

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

Related links

• Eric Meyer's mode about Mac IE5 written in using correct doctype
• Mozilla's doctype sniffing by David Baron
• Lance Silver discusses patterns and doctype sniffing in Windows IE6 in CSS enhancement
• Opera9's doctype conversion
• Faruk Ateş's IE8 and X-UA-Compatible Solutions

Supplement: Requests to XML implementers and standard authors

Please do not bring doctype sniffing to XML.

Doctype sniffing is to solve a problem of labeled chowder soup using a chowder soup-like method. Doctype sniffing is a tentative approach designed after the release of HTML4 and CSS2 specifications, which distinguishes outdated documents from documents to match behaviors that their authors might expect.

Occasionally it is suggested to use doctype sniffing on XML to schedule different processing, identify the vocabulary being used, or to activate features. This is a bad idea. Scheduling and vocabulary recognition should be based on namespace, while feature activation should be based on explicit processing instructions or elements.

The whole idea of ​​well-formedness is to introduce DTD parsing that allows XML, and promote doctype-free documents. In formal cases, two XML documents have the same canonical form and the application processes them differently (and not because there is no choice to handle external entities), the application may be broken. In practice, if two XML documents cause the same content to be reported (qnames ignore) to the SAX2 content processor and the application processes the document differently, the application may be broken. Considering that as a web author it is impossible to believe that everyone will parse their pages using XMLprocessors that address additional entities (even if some browsers seem to do so, as they map certain public identifiers to a DTD that defines the entity with an abridged), inserting doctype into XML for use in the Web is meaningless and often leads to cargo cultish habits. (You still use the DTD override feature of the W3C validator to verify a DTD, although the W3C validator will say the result is only temporary. Or better yet, you can use relaxing NG verification, which does not pollute the document referenced by the pattern.) It is very silly to require doctype for sniffing, even if that is a workaround in HTML practice.

Furthermore, when a low-level specification defines two equal things, a high-level specification should not try to give them different meanings. Please 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 deleted, the same DTD is still specified, so 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? It can be further theory. Suppose copy to example.com a DTD called foobar.dtd: <!DOCTYPE html SYSTEM http://example.com/foobar.dtd>. How to sniff this? It should have the same meaning. Even the entire DTD can be posted in the document.

In other words, if there is #include foo.h, you should not bind any black magic to the name foo.h, as it should allow copying of the contents of foo.h into the document or copying foo.h into bar.h and representing #include bar.h.

The reason I'm not worried about HTML and SGML constructing the same parameters is that the web browser does not use a real SGML parser to parse HTML, so I think it's useless to masquerade as SGML for processing. Anyway, if you don't believe it yet, please read W. Eliot Kimber's article on this matter comp.text.sgml

Appendix: Some doctype processing methods in text/html

In the following table, the quirk pattern, the standard pattern and the quasi-criteria are represented as Q, S, and A, respectively. When the browser has only two modes, the standard mode is marked as S if the row height of the table cell is consistent with the standard mode performance of Mozilla, and the standard mode is marked as A if the row height of the table cell is consistent with the standard mode performance of Mozilla.

Please note that XHTML serving 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 creating new pages. The purpose of this table is to show what kind of data my recommendations are based on.

The following abbreviation symbols are used for column titles:

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 to Netscape 7, Safari 0.9 to Safari 4.0 beta, Opera 10, Chrome, Konqueror 3.5, HTML5 specified behavior

Opera 9.0

Opera 9.0…9.20

IE 8 & Opera 9.5

Default IE8 without X-UA-Compatible and Compatible Mode override (A means IE8 quasi-standard mode in this case), Opera 7.5…8.54 and 9.5…9.6

IE 7 & Opera 7.10

IE7, compatible mode and without X-UA-Compatible coverage (A means IE7 mode in this case) 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 (may also include 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. The states established by Mozilla (and Netscape 6.x) described in this document can be seen on ftp.mozilla.org since 2000.10.19. This document does not address how doctype sniffing works in Mozilla M18 (and Netscape 6.0 PR3). Safari's doctype sniffing code has also been greatly modified since the first public beta. This document does not include behaviors earlier than version V73, also called 0.9.

The doctype sniffing code before Konqueror3.5 seems to come from an early version of Safari. Konqueror now matches Safari, and its doctype sniffing code comes from Mozilla.

As can be seen from the table, Opera's doctype sniffing is changing from a regular IE-like to a Mozilla-like, although Opera9.5 and 9.6 are on the way backwards. Meanwhile, the layout behavior of Opera quirk mode has been switched from imitating IE6's quirk mode to Mozilla's quirk mode.

Appendix: Mode selection for IE8

Start: Enter X-UA-Compatible meta?

X-UA-Compatible meta?

IE=7: Use IE7 standard

IE=EmulateIE7: Enter quirk or no doctype? (compatible mode)

IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or script does not appear first: Enter the X-UA-Compatible HTTP header?

IE=8 or IE=Edge or IE=99 or IE=9.9: Enter quasi-standard mode?

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

X-UA-Compatible HTTP header?

IE=7: Use IE7 standard mode

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

IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or None: Enter to display all sites...Preset?

IE=8 or IE=Edge or IE=99 or IE=9.9: Enter quasi-standard mode?

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

Quirk mode or no doctype? (compatible mode)

Yes: Use Quirk Mode (IE5.5)

No: Use IE7 standard mode

Show all sites...presets?

Yes: Enter quirk mode or no doctype? (compatible mode)

No: Enter the display local website point...Preset?

Show local site points...preset?

Yes: The entry site is located in the LAN domain?

No: Enter the domain name on the list maintained by Microsoft?

Domain names are on the list maintained by Microsoft?

Yes: Enter quirk mode or no doctype? (compatible mode)

No: Enter the compatible mode page to embed with Frame?

Embedded with Frame by compatible mode page?

Yes: Enter quirk mode or no doctype? (compatible mode)

No: Enter the Compatibility Mode button is pressed?

The Compatibility Mode button was pressed?

Yes: Enter quirk mode or no doctype? (compatible mode)

No: Enter quirk mode or no doctype? (IE8)

Quirk mode or no doctype? (IE8)

Yes: Enter the use of quirk mode (IE5.5)

No: Enter quasi-standard mode?

Quasi-standard mode?

Yes: Use IE8 quasi-standard mode

No: Use IE8 standard mode

These steps can be seen through the flowcharts in PDF and PNG formats.

Acknowledge

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