本文包含的模式轉換（mode switching）適用於Firefox和其他基於Gecko的瀏覽器，Safari、Chrome和其他基於Webkit的瀏覽器，Opera、 Konqueror、Mac版Internet Explorer、Windows版Internet Explorer和內嵌版IE的瀏覽器。避免提及瀏覽器引擎的名字，取而代之的是使用該引擎最知名瀏覽器的名字。
本文著重介紹模式的選擇機制，而不是記錄每個模式的確切行為。
以下是各種不同的模式：
text/html內容的模式選擇取決於doctype嗅探（doctype sniffing，本文後面有討論）。在IE8中，模式也取決於其他因素。然而在IE8的預設情況下，那些不在微軟提供黑名單上的非區域網路（non- intranet）網站的模式取決於文件類型。
再怎麼強調每個瀏覽器中模式精確行為的不同也是不過分的，即使本文中進行了統一的討論。
Firefox、Safari、Chrome和Opera中，application/xhtml xml HTTP內容類型（不是meta元素也不是doctype!）會觸發XML模式。在XML模式中，瀏覽器嘗試給予XML文件在規範上的正確處理達到在製定瀏覽器中的程度。
IE6、7和8不支援application/xhtml xml，Mac IE5也是如此。
基於WebKit的Nokia S60 瀏覽器中，application/xhtml xml HTTP內容類型不能觸發XML模式，因為在移動的圍牆花園（mobile walled gardens）中關注點是對不規範內容的兼容性。 （舊式的「行動瀏覽器」無法使用真正的XML解析器，因為不規範內容已被標記為XML。）
由於沒有充分測試Konqueror，我無法確切地說出在這個瀏覽器中會發生什麼。
某些引擎擁有的模式與Web內容無關。為了完整性，它們只是在這裡被提到。 Opera有WML2.0模式。 Leopard上的WebKit有個舊式Dashboard widgets的特定模式。
以下是這些模式的主要影響：
text/html的模式主要是影響CSS佈局。例如，表格不繼承樣式是個怪癖。在某些瀏覽器的怪癖模式下，盒子模型（box model）變成IE5.5的盒子模型。本文檔沒有列舉出所有的佈局怪癖。
準標準模式（有這種模式的瀏覽器中）中，僅包含圖片的表格單元格的高和標準模式中不同。
XML模式中，選擇器有不同的區分大小寫行為。此外，用於HTML body元素的特有規則不能套用在那些沒有實作最新CSS2.1改變的較舊版本的瀏覽器。
也有一些怪癖影響HTML和CSS的解析且會導致符合標準的網頁被錯誤解析。怪癖佈局決定了這些怪癖是否開啟。無論如何，了解怪癖模式和標準模式在CSS佈局和解析（非HTML解析）上的主要異同是非常重要的。
有些人錯誤地把標準模式稱為“嚴格解析模式（strict parsing mode）”，其讓人誤解了瀏覽器強制執行HTML語法規則和用瀏覽器評估標記的正確性。情況並非如此。即使標準模式佈局生效時，瀏覽器仍會做標籤雜燴湯（tag soup，http://en.wikipedia.org/wiki/Tag_soup）修正工作。 （在2000年Netscape6發布前，Mozilla的確有用於強制執行HTML語法規則的解析模式。這些模式和現有的Web內容不相容而被遺棄。）
另一個常見的誤解是關於XHTML解析的。通常認為用XHTML doctype得到不同的解析。其實並非如此，內容類型是text/html的XHTML文件所用解析器和HTML文件的是同一個。目前瀏覽器在意的是文檔類型為text/html的XHTML僅是「撒麵包丁的標籤雜燴湯（tag soup with croutons）」（到處是額外的斜線）。
僅當使用XML文件類型的文件（例如：application/xhtml xml或xmapplication/）會觸發XML模式來解析，這時的解析器完全不同於HTML解析器。
雖然怪癖模式主要是關於CSS的，但也有一些是關於腳本的。例如，Firefox的怪癖模式中，HTML id 屬性像在IE一樣建立了全域腳本作用域的物件參考。 IE8中關於腳本的影響比其他瀏覽器更值得關注。
XML模式中，某些DOM API的行為徹底不同，因為XML的DOM API行為被定義時不相容HTML的行為。
現代瀏覽器使用doctype嗅探來決定text/html文件的引擎模式。這意味著模式的選擇是基於HTML文件開始的文件類型聲明（或缺少）。 （這不適於使用XML文件類型的文件。）
文件類型宣告（doctype）是SGML的語法偽造，SGML是個舊式的標記框架，HTML5之前的HTML就是依據其定義的。 HTML4.01規格中，文件類型宣告描述的是HTML的版本資訊。儘管名字叫做“文檔類型聲明”且HTML 4.01規範所描述的是關於“版本資訊”，文檔類型聲明並不適用把SGML或XML文檔分類為特定類型的文檔，即使它看起來像是（因為名字） 。 （更多內容在附錄）
HTML4.01規格和ISO 8879（SGML）都沒有說關於使用文件類型宣告作為引擎模式轉換的任何事情。 doctype嗅探是基於觀察，在doctype嗅探被設計時，絕大部分的怪癖文檔既沒有文檔類型聲明也沒有引用舊的DTD。 HTML5接受這個事實，定義了text/html中doctype作為唯一的模式轉換。
典型的預HTML5（pre-HTML5）文檔類型聲明包含（被空白分開）“字串，根元素（“html”）的通用標識符， “PUBLIC”字串，處於引號中的DTD公共標識符，同一DTD的可能係統標識符（URL）和字元“>”。文檔類型聲明位於文檔的根元素開始標籤之前。
以下是建立新的text/html文件時如何選擇doctype的簡單指南：
我不推薦任何的XHTML doctype，因為XHTML被用作text/html被認為是有害的。無論如何，如果你選擇使用XHTML doctype，請注意XML宣告會使IE6（但不是IE7！）觸發怪癖模式。
application/xhtml xml的簡單指南是絕不使用doctype。該方式下的網頁不是「嚴格一致」的XHMTL1.0，但這並不重要。 （見後面的附錄）
A List Apart 曾介紹 ，IE8除doctype外會使用基於meta元素的模式轉換作為模式選擇的因素之一。 （見Ian Hickson、David Baron、David Baron again、Robert O'Callahan 和Maciej StawiakIE8有4種模式：IE5.5怪癖模式、IE7標準模式、IE8 準標準模式 和IE8標準模式。模式的選擇取決於來自幾個方面的資料：doctype、meta元素、HTTP頭、微軟的定期下載資料、區域網域、使用者所做設定、區域網路管理員所做設定、父框架的模式（如果有）和網址列相容視圖按鈕被使用者觸發。 （對於嵌入該引擎的其他應用，模式也取決於嵌入的應用。）
幸運的是如果出現下列情況，IE8大體上會像其他瀏覽器一樣使用doctype嗅探：
作者沒有設定X-UA-Compatible HTTP頭
在 X-UA-Compatible 情況下，IE8的行為和其他瀏覽器完全不同。想看本頁的附錄或PDF和PNG格式的流程圖。
不幸的是，沒有X-UA-Compatible的HTTP頭或meta標籤，即使使用了合適的doctype，IE8讓用戶無意間使頁面從IE8的標準模式降到IE7模式，這是一種仿真的IE7標準模式。更糟的是，區域網路管理員也可以這麼做。微軟也可以把你所使用的所有網域到列入黑名單。
為了對付這些影響，doctype是不夠的，你需要X-UA-Compatible HTTP頭和meta標籤。
下面的簡單指南是針對已經有doctype在其他瀏覽器觸發標準模式或準標準模式的新的text/html文件如何選擇X-UA-Compatible HTTP頭或meta標籤的：
請不要把doctype嗅聞帶到XML。
doctype嗅聞是用簽雜燴湯似的方法解決一個標籤雜燴湯問題。 doctype嗅探是在HTML4和CSS2規範發布後設計的一種試探方法，它從文件中區分出過時文件以符合其作者可能期望的行為。
偶爾有人建議在XML上使用doctype嗅探來調度不同的處理、識別正在使用的詞彙表或活化特性。這是個壞主意。調度和詞彙表辨識應該是基於名字空間的，而特性活化應該是基於明確的處理指令或元素。
良構（well-formedness）的整個想法是介紹允許XML的無DTD解析，並推廣無doctype文件。在正式情況下，兩個XML文件有相同的規範形式且應用不同地處理它們（且不同之處並非因為沒有選擇處理外部實體），這個應用或許被破壞了。在實務情況下，如果兩個XML文檔導致同樣的內容被報告（qnames忽略）給SAX2內容處理器且應用不同地處理文檔，這個應用或者被破壞了。考慮到作為Web作者無法相信每個人都會使用解決額外實體的XMLprocessor來解析其頁面（即使一些瀏覽器看起來這樣做，因為它們會映射一定公共的標識符到一個有刪節的定義實體的DTD），插入doctype到XML中用於Web是毫無意義的且通常會導致貨運崇拜（cargo cultish）習慣。 (您仍然使用W3C驗證器的DTD覆蓋功能來對一個DTD進行驗證，雖然W3C驗證器會說結果只是暫時有效。或更好的是，你可以用放寬NG驗證，它不會污染模式引用的文檔。
此外，當低階的規範定義兩個相等的東西時，高層次的規範不應該嘗試給它們不同的意義。請考慮。如果刪除公共識別符，依舊指定了相同的DTD，因此doctype 表示和前面的doctype一樣。應該不同地嗅探它們麼？可以進一步理論。假設複製給example.com一個叫做foobar.dtd的DTD：。這該如何嗅探？應該是同一個意思。甚至整個DTD可以貼在文件中。
換句話說，如果有#include “foo.h”，你不應該給名字foo.h綁定任何black magic，因為它應該允許複製foo.h的內容到文檔中或複製foo.h到bar.h中且表示#include “bar.h”。
我不擔心HTML和SGML構造相同的參數的原因是Web瀏覽器不會使用真正的SGML解析器去解析HTML，所以我認為偽裝成SGML進行處理是沒有用的。無論如何，如果你還不相信，請看W. Eliot Kimber關於此事的文章 comp.text.sgml
下表中，怪癖模式、標準模式和準標準分別表示為Q、S和A。當瀏覽器僅有兩種模式時，如果表格單元格的行高和Mozilla的標準模式表現一致時，標準模式標記為“S”，如果表格單元格的行高和Mozilla的準標準模式表現一致時，則標記為“A”。
請注意使用XML內容模型提供服務的XHTML在XML模式下渲染。
本表的目的並不是說表中所有的doctype都是新頁面的合理選擇。本表的目的是為了展示我的推薦是依據什麼樣的數據。
下列的簡寫符號是用於列標題：
Moziila的doctype嗅探程式碼在2000年10月、2001年9月和2002年6月有大幅的修改。本文檔所描述的Mozilla（和 Netscape 6.x）建立的狀態可以自2000.10.19起在ftp.mozilla.org上看到。本文檔未涉及Mozilla M18（和Netscape 6.0 PR3）中的doctype嗅探的工作方式。 Safari的doctype嗅探程式碼自第一個公開的測試版起也有大幅的修改。本文檔不包括比版本V73也叫0.9更早的行為。
Konqueror3.5之前的doctype嗅探程式碼似乎來自於Safari的很早的一個版本。 Konqueror現在和Safari匹配，其doctype嗅探代碼來自Mozilla。
從表中可見，Opera的doctype嗅探正由規律的從類似IE向類似Mozilla轉變，雖然Opera9.5和9.6在倒退的路上。同時，Opera怪癖模式的佈局行為已從仿效IE6的怪癖模式轉換為Mozilla的怪癖模式。
怪癖模式或無doctype?(IE8) 是：進入「使用怪癖模式（IE5.5）」 否：進入「準標準模式？」
是：使用IE8準標準模式
否：使用IE8標準模式 這些步驟都可以透過PDF和PNG格式的流程圖看到。 鳴謝 感謝Simon Pieters、Simon Pieters和Anne van Kesteren幫助我改正了各種Opera版本的模式表和他們的評論。感謝Simon Pieters製作了另一份IE8的流程圖。
