通過 Doctype 啟用瀏覽器模式
為了即能解析那些滿足Web標準的網頁，又能解析那些過去20年來遺留下來的傳統的網頁，現代瀏覽器一般都實現了多種網頁解析的模型。本文將介紹這些解析模型都是什么，以及它們是如何觸發的。
內容概述
本文檔的主要結論是，你應當在你HTML文檔（所有以text/html類型處理的內容）的源代碼頂部加上<!DOCTYPE html>。（詳見下文）
如果你還想確保使用IE8/IE9/IE10的用戶不做任何操作就可以讓網頁以IE7的形式顯示，你可以在你的服務器上為所有text/html的響應添加HTTP頭"X-UA-Compatible: IE=Edge"，還可以在HTML文檔的head內的最上方加上<meta http-equiv="X-UA-Compatible" content="IE=Edge">。然而這將會導致HTML文檔不能通過校驗（HTML document invalid）。其實即使你不加上這些IE-specific聲明，IE大部分情況下的默認行為也是合理的，因此，你也不需要對這些IE-specific過于依賴。（下文將會介紹例外的情況）
本文檔的適用范圍
本文檔幾乎覆蓋了所有的瀏覽器，包括以Firefox為代表的Gecko內核的瀏覽器、以Safari/Chrome為代表的Webkit內核的瀏覽器、Opera、Konqueror、IE for Mac、IE for Windows/Windows Phone以及那些內嵌IE內核的其它瀏覽器。下面我們將不再使用這些瀏覽器引擎的名稱，而是以各引擎的典型瀏覽器的名稱來代替。
本文檔重點說明的不是這些模式的具體行為，而是它們的選擇機制。希望能讓你明白如何避免（不小心使用）那些過期的模式，而不是告訴你如何故意使用這些過期的模式實現最佳的行為。
模式介紹
本文將介紹以下這些模式:
適用于text/html類型的常見模式
對text/html類型的內容來說，模式的選擇取決于對文檔的doctype探測（參見下文的doctype探測章節）。在IE8及更高版本的瀏覽器中，模式還取決于一些其它因素。在IE8及更高版本瀏覽器，對于不在微軟提供的黑名單上的網站，模式取決于doctype。如果安裝了Google Chrome Frame，將會受到另外一些因素的影響，甚至會影響到IE6和IE7。
-
怪癖模式（Quirks Mode）
在怪癖模式中，為了避免“破壞”那些根據上世紀90年代末流行的實踐創作的頁面，瀏覽器違反了現代的Web格式規范。不同的瀏覽器實現了不同的怪癖行為。以前，不同的瀏覽器實現了不同的怪癖模式，比如IE6/7/8/9里的怪癖模式就是IE5.5模式，其它瀏覽器的怪癖模式則是對近乎標準模式的一種修改。最近各瀏覽器已經開始在它們的怪癖模式里應用相同的行為，尤其要提到的是IE10的怪癖模式已不再模仿IE5.5，而是與其它瀏覽器的怪癖模式保持一致。目前WHATWG正在制定怪癖模式的標準。
和其它瀏覽器中的怪癖模式一樣，IE10的怪癖模式有時會被稱為"互操作性怪癖模式"(interoperable Quirks mode）以與IE10的模仿IE5.5的怪癖模式（Internet Explorer 5 Quirks）進行區別。
如果你正在編寫一個新的頁面，請使用標準模式，而堅決不要使用怪癖模式。
-
標準模式（Standards Mode）
標準模式中，這些瀏覽器將嘗試以各自實現的程度規范正確地處理文檔。。
不同的瀏覽器遵循不同的階段，所以標準模式也不是一個單一目標。
HTML標準中稱這種模式為 “非怪癖模式”（no quirks mode）。
-
近乎標準模式（Almost Standards Mode）
Firefox, Safari, Chrome, Opera (從7.5開始), IE8, IE9 and IE10 還有一個稱為近乎標準模式（the Almost Standards mode）的模式，這種模式以傳統的方式設定表格的垂直高度，而沒有遵從CSS2的標準。Mac IE 5、Windows IE 6/7、Opera prior to 7.5以及Konqueror并不需要該模式，因為這些瀏覽器的標準模式也沒有按照CSS2的標準設定表格的垂直高度。事實上，相對于較新的瀏覽器的標準模式，它們的標準模式更接近于近乎標準模式。回顧過去, 如果沒有"標準模式"與"近乎標準模式"的區別，Web或許會更好，可以默認使用近乎標準模式的行為，再利用樣式表特性選擇標準模式下的行為。然而，你還是應該用標準模式，而不要用近乎標準模式。HTML標準中稱這種模式為有限怪癖。
適用于application/xhtml+xml類型的模式（XML模式）
在Firefox, Safari, Chrome, Opera 和 IE9 里，如果HTTP響應中的Content-type是application/xhtml+xml時會觸發XML模式，需要強調的是觸發條件是HTTP的 Content-type，不是HTML中的<meta...>元素，也不是HTML的doctype。在XML模式下，這些瀏覽器將以各自實現的程度規范正確地處理XML文檔。
IE6/7/8不支持application/xhtml+xml，Mac版的IE5也不支持。
在基于Webkit的Nokia S60瀏覽器上，由于考慮到在圍墻花園（譯者按：walled garden，指的是一個控制用戶對網頁內容和服務進行訪問的環境，圍墻花園把用戶限制在一個特定的范圍內，它允許用戶訪問指定的內容，同時防止用戶訪問其他未被允許的內容。）環境下對病態內容的兼容性，application/xhtml+xml的HTTP Content-type并不觸發XML模式。因為傳統的移動瀏覽器并沒有使用真正的XML解析器，那些病態內容也會被作為XML對待。
我并沒有測試 Symbian3上的默認瀏覽器。
我沒有對Konqueror進行過充分的測試，不好說這個瀏覽器的具體行為。
微軟額外提供的一些IE-Specific模式
下面列出了一些額外的IE-specific模式，這些模式并不適用于HTML5，也不適用于其它不支持這些模式的瀏覽器，它們通過配置來激活，還可以通過"X-UA-Compatibleas"的HTTP頭，或者html里的meta元素進行激活。
-
Internet Explorer 5 Quirks
除了互操作性怪癖模式外，IE10還有一個稱為Internet Explorer 5 Quirks的模式，它模仿了IE5.5的行為，這種模式在IE6/7/8/9中稱為怪癖模式。
-
Internet Explorer 7 Standards
IE8/9/10使用該模式模擬IE7的標準模式。
-
Internet Explorer 8 Standards
IE9/10使用該模式模擬IE8的標準模式。
-
Internet Explorer 8 Almost Standards
IE9/10使用該模式模擬IE8的近乎標準模式行為。在界面上的開發者工具箱中，這個模式與IE8標準模式沒什么區別。
-
Internet Explorer 9 Standards
IE9/10使用該模式模擬IE9的標準模式。
-
Internet Explorer 9 Almost Standards
IE10使用該模式模擬IE9的近乎標準模式行為。在界面上的開發者工具箱中，這個模式與IE9標準模式沒什么區別。
-
Internet Explorer 9 XML
IE10使用該模式模擬IE9的XML模式行為。在界面上的開發者工具箱中，這個模式與IE9標準模式沒什么區別。
值得注意的是，對上一版本的IE的模擬并不夠完美，我自己就遇到過一些例子：比如在IE7以上的版本中使用IE7的標準模式對@font-face（像 EOT字體）的處理是不同的；還有，在IE10的IE9模式下CSS的2D變換是不需要-ms-前綴的，但是真正的IE9卻需要該前綴。如果你認同本文給出的建議，請不要過于關注這些模式，這些兼容模式也將不會對你的產品帶來不好的影響。然而對于快捷測試來說，相對于在虛擬機中使用老版本的IE進行測試，還不如在一個較新的IE上使用不同的兼容模式進行測試。
另外，IE10的Windows Phone版與Windows桌面版相同，都有上面所說的這些模式。
Google額外提供的一些IE-Specific模式
當安裝了Google Chrome Frame后，IE6/7/8/9（不包括Windows8以及2013年2月的Windows7上的IE10）還可提供以下這些額外的模式。
-
Chrome Quirks
此模式相當于Google Chrome上的怪癖模式。
-
Chrome Standards
此模式相當于Google Chrome上的標準模式。
-
Chrome Almost Standards
此模式相當于Google Chrome上的近乎標準模式。
非Web模式
有些模式還提供了一些與Web內容不相關的模式。在這里提到這些模式僅僅出于對此文檔的完整性考慮。包括Opera的WML2.0模式，Mac OS X 10.5上WebKit瀏覽器上的特殊模式（用于傳統的Dashboard widgets，或許這個模式目前仍有更新，我沒有考察不是很確定）。以及為Mac OS X上內嵌WebKit瀏覽器的應用程序單獨提供的模式。
模式的影響
模式的主要影響如下:
頁面布局
除IE外，對于text/html類型的模式主要影響樣式表布局以及樣式系統。例如，表格內不會繼承樣式表；在IE和Opera的老版本中的怪癖模式下，盒模型變成了IE5.5的盒模型。本文檔并不會枚舉所有的怪癖布局，你可以查閱 Mozilla文檔 以及 怪癖模式標準 獲得完整列表。
在近乎標準模式中（在所有包含此模式的瀏覽器中），僅含有圖片的單元格高度的計算方式與標準模式不同。
在XML模式中，選擇器對查詢條件的大小寫有不相同的處理行為，另外，對于那些沒有實現更多的樣式表規范的老版本瀏覽器中，并不包含對body元素的特殊規則。
內容解析
也有一些差異會影響到HTML和CSS的解析，并且可能會導致一些正常的頁面被錯誤的解析。 這些差異會隨著對布局的影響而同時產生影響。重要是要知道怪癖模式和標準模式的主要差別在于CSS布局和CSS的解析，而不是對HTML的解析。對于已經兼容HTML5的瀏覽器，也有一些關于HTML解析的差異。
一些人會把標準模式誤認為是“嚴格解析模式”，他們會覺得這樣的話，瀏覽器會強制遵守HTML語法規則，會對HTML標記的正確性進行評估。事實上既然在標準模式下，瀏覽器仍會對HTML標簽進行必要的修復。（2000年夏，Netscape 6 發布前，Gecko瀏覽器確實包含一些強制按HTML語法規則進行解析的模式，其中一種模式稱為“標準定義”，這些模式并不能兼容目前的網頁內容，已經過期了。）
另外一個常見的誤解是關于解析XHTML的。大家通常認為聲明為XHTML的doctype會帶來不同的解析。事實上XHTML文檔也是text/html類型的，也只是“蛋花標簽湯”而已，到處都是額外的斜線》只有文檔以XML類型（如application/xhtml+xml或application/xml）輸出時才會觸發與HTML解析完全不同的XML模式的解析。
腳本
雖然怪癖模式主要影響的是CSS，但是還有一些腳本也會受到影響。直到Firefox14，其近乎標準模式下，還是不能直接使用標簽的ID來引用標簽對象。在Firefox的怪癖模式中有document.all對象，但是在其它模式中卻沒有該對象。當在IE中模擬低版本IE時，這些影響更搞笑。
在XML模式中，一些DOM API表現很不一樣，因為對XML的DOM API與HTML是完全不同的，唉，實在很遺憾。
doctype嗅探（也叫doctype轉換）
現代瀏覽器使用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）文檔類型聲明包含（被空白分開）“<!DOCTYPE”字符串，根元素（“html”）的通用標識符， “PUBLIC”字符串，處于引號中的DTD公共標識符，同一DTD的可能系統標識符（URL）和字符 “>”。文檔類型聲明位于文檔的根元素開始標簽之前。
選擇Doctype
text/html
下面是創建新的text/html文檔時如何選擇doctype的簡單指南：
-
標準模式，最前沿的驗證
<!DOCTYPE html>
如果想驗證諸如<video>、<canvas>和ARIA這樣的新特性，那么這樣做是對的。注意，HTML5的有效定義依舊在變化中，請確保在Firefox、Safari、Chrome、Opera9或Opera10中測試圖像對齊。在Internet Explorer中測試圖像對齊是不足夠的，無論如何請確保在IE8中也進行了測試。
-
標準模式，更穩定的驗證目標
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
這個doctype也會觸發標準模式，但是由于對新功能不了解，這些傳統的驗證不是很精確，為避免你的組織需要進行對驗證目標的守舊的策略。你還是應該把使用<!DOCTYPE html>修改為你們組織的設計策略。
另外，如果你使用表格顯示切片圖像，你最好使用標準模式。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
它會觸發近乎標準模式。請注意，如果以后移植到HTML5上，基于利用表格實現的切片圖像的布局可能會被破壞（完整標準模式也如此）。所以最好現在就確認你的設計是兼容標準模式的吧。
-
故意要使用怪癖模式
沒有doctype。
請別這樣做。故意為怪癖模式所做的設計將會困擾你、你的同事以及你未來的繼任者。
如果你仍然想支持IE6，對IE6使用條件注釋做一個特別的hack比應用怪癖模式更好。
我不推薦任何的XHTML doctype，因為XHTML被用作text/html被認為是有害的。如果你選擇使用XHTML doctype，那么請注意XML聲明會使IE6觸發怪癖模式（IE7不會）。
application/xhtml+xml
對application/xhtml+xml的簡單指南是絕不使用doctype。該方式下的網頁不是“嚴格一致”的XHTML1.0，但這并不重要。（請看后面的附錄）
IE8/9/10相關的問題
A List Apart上的這篇文章介紹說，IE8除doctype外會使用基于meta元素的模式轉換作為模式選擇的因素之一。（請看Ian Hickson、David Baron、David Baron again、Robert O’Callahan和Maciej Stachowiak的評論。）
IE8有4種模式：IE5.5怪癖模式、IE7標準模式、IE8 近乎標準模式和IE8標準模式。IE9有7種模式：IE5.5怪癖模式、IE7標準模式、IE8 近乎標準模式、IE8標準模式、IE9 近乎標準模式、IE9標準模式和IE9 XML模式。IE10有11種模式：IE5.5怪癖模式、IE7標準模式、IE8 近乎標準模式、IE8標準模式、IE9 近乎標準模式、IE9標準模式、IE9 XML模式、IE10怪癖模式、IE10近乎標準模式、IE10標準模式以及IE10 XML模式。模式的選擇取決于來自幾個方面的數據：doctype、meta元素、HTTP頭、來自微軟的定期下載數據、局域網域、用戶所做設置、局域網管理員所做設置、父框架的模式（如果有）和地址欄兼容視圖按鈕被用戶觸發。（對于嵌入該引擎的其他應用，模式也取決于嵌入的應用。）
幸運的是如果出現下列情況，IE8/9大體上會像其他瀏覽器一樣使用doctype嗅探，而IE10則會嚴格地使用doctype進行嗅探：
-
作者沒有設置X-UA-Compatible HTTP頭
-
作者沒有設置X-UA-Compatible meta標簽
-
域名沒有被微軟添加到黑名單中
-
局域網管理員沒有把該站點放置到黑名單上
-
用戶沒有按下兼容視圖按鈕(或以其他方式添加到某個特定的用戶黑名單中) (Metro IE10 沒有此按鈕, 但是桌面里IE10的兼容視圖也會影響到Metro模式下的IE10)
-
該站點不在局域網域中
-
用戶沒有選擇以IE7模式顯示所有站點
-
頁面沒有通過frame嵌入到兼容模式的頁面中
上述除兩個關于X-UA-Compatible的情況外，IE8/9像IE7一樣執行doctype嗅探。IE7 emulation就是兼容視圖。
在 X-UA-Compatible 情況下，IE8/9的行為和其他瀏覽器完全不同。想看本頁的附錄或PDF和PNG格式的流程圖。 (與其它瀏覽器圖表的對比：PDF格式) 還有一個從IE5.5到IE9的統一的圖 (包括了 Chrome Frame)：PDF格式. (我打算做一個只包含IE9的這么一張圖)
不幸的是，沒有 X-UA-Compatible的HTTP頭或meta標簽，即使使用了合適的doctype，IE8/9讓用戶無意間使頁面從標準模式降到IE7模式，這是一種仿真的IE7標準模式。更糟糕的是，局域網管理員也可以這么做。微軟也可以把你所用的所有域名到列入黑名單（比如mit.edu）。
為了對付這些影響，doctype是不夠的，你需要X-UA-Compatible HTTP頭和meta標簽。
如果一個新的頁面已經使用doctype觸發了其它瀏覽器的標準模式，或者近乎標準模式。那么下面的內容將指導你如何利用X-UA-Compatible HTTP頭或meta標簽：
-
你的域名沒有在微軟的黑名單上，而且你更關心網頁里沒有使用那些令人討厭的瀏覽器專屬內容，而不在乎用戶能不能使用IE7模式顯示你的網頁。
你不需要添加X-UA-Compatible HTTP頭或meta標簽。
-
你的域名在微軟的黑名單中，或者你的域名里有些網頁有問題而導致用戶可能會對整個域啟用兼容視圖，你擔心Google或Digg用frame嵌入你的站點，或你想確保用戶不能對你的網頁使用兼容視圖
你可以將此meta標簽添加在你的網頁里所有腳本之前（在HTML5中該標簽是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=Edge">；或者為你的頁面設置此HTTP頭：X-UA-Compatible: IE=Edge。
-
你的網站在IE7下運行良好，在IE8/9下不能正常運行
首先你可以將此meta標簽添加在你的網頁里所有腳本之前（在HTML5中該標簽是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">；或者為你的頁面設置此HTTP頭：X-UA-Compatible: IE=EmulateIE7。
然后將你的網站修復為不依賴任何非IE7標準的內容，并遷移到IE=Edge。
-
你的網站在IE8下運行良好，在IE9下不能正常運行
首先你可以將此meta標簽添加在你的網頁里所有腳本之前（在HTML5中該標簽是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8">；或者為你的頁面設置此HTTP頭：X-UA-Compatible: IE=EmulateIE8。
然后將你的網站修復為不依賴任何非IE8標準的內容，并遷移到IE=Edge。
-
你的網站在IE9下運行良好，在IE10下不能正常運行
首先你可以將此meta標簽添加在你的網頁里所有腳本之前（在HTML5中該標簽是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">；或者為你的頁面設置此HTTP頭：X-UA-Compatible: IE=EmulateIE9。
然后將你的網站修復為不依賴任何非IE9標準的內容，并遷移到IE=Edge。
Google Chrome Frame相關的問題
Google Chrome Frame 是一個適用IE6/7/8/9的瀏覽器擴展和插件，它使用IE的網絡連接但是添加了Google Chrome引擎。安裝之后默認還是IE的行為，但是網頁卻可以使用一個X-UA-Compatible的HTTP頭，或者一個meta標簽切換到Chrome引擎上。
在任何安裝了Chrome Frame的瀏覽器環境下設置X-UA-Compatible為chrome=1，都會激活Chrome Frame。如果設置X-UA-Compatible為chrome=IE6，則只會為IE6激活Chrome Frame。如果設置X-UA-Compatible為chrome=IE7，則只會為IE6和IE7激活Chrome Frame。如果設置X-UA-Compatible為chrome=IE8，則只會為IE8及以下的瀏覽器激活Chrome Frame。
這些激活Chrome Frame的指令可以與激活其它IE兼容模式的指令合并起來一起控制IE使用的引擎，使用逗號或分號將這些指令分隔即可，比如：<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE8">。
網頁一旦激活了Chrome Frame，那么就像在普通的Chrome里那樣的選擇這四種模式（標準模式、近乎標準模式、怪癖模式、XML模式）之一了。
但是，還有兩個避免使用Chrome Frame的關鍵因素：
-
Chrome Frame不支持IE的可訪問性支持。如果激活了Chrome Frame，IE里的內容區域就不能使用IE的可訪問性支持了，這就意味著屏幕閱讀器以及Window語音識別不能在Chrome Frame下正常運行。
-
你的網站應該告訴那些將要安裝Chrome Frame的用戶，啟用網站安裝防御模式，以告訴用戶他們為了使用這個網站需要在本機安裝一個有權限的本地代碼插件。
相關網頁鏈接
-
Eric Meyer寫的關于Mac IE 5的模式 Use the Right Doctype
-
Mozilla’s DOCTYPE sniffing 作者：David Baron
-
CSS Enhancements in Internet Explorer 6 作者：Lance Silver，討論了Windows IE6的模式以及doctype嗅探
-
Faruk Ate?寫的關于IE8的 IE8 and the X-UA-Compatible situation
補遺：對XML的實現者和規范作者的懇求
請不要把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驗證，它不會污染模式引用的文檔。)為了嗅探而要求doctype是非常愚蠢的，即使那是在HTML實踐中的解決方法。
此外，當低級別的規范定義兩個相等的東西時，高級別的規范不應該嘗試給它們不同的含義。請考慮<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">。如果刪除公共標識符，依舊指定了同樣的DTD，因此doctype<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">表示和前面的doctype一樣。應該不同地嗅探它們么？可以進一步理論。假設復制給example.com一個叫foobar.dtd的DTD：<!DOCTYPE html SYSTEM "http://example.com/foobar.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’s comp.text.sgml post about the matter。
附錄：text/html中一些doctype的處理方式
下表中，怪癖模式、標準模式和近乎標準分別表示為Q、S和A。當瀏覽器僅有兩種模式時，如果表格單元格的行高和Mozilla的標準模式表現一致時，標準模式標記為“S”，如果表格單元格的行高和Mozilla的幾乎標準模式表現一致時，則標記為“A”。
請注意使用XML內容模型的XHTML將會以XML模式進行渲染。
本表中所有的doctype并不都是新建頁面的合理選擇。本表只是列出了我推薦所依據的數據。
以下是表頭的說明：
-
NS6：Mozilla 0.6…0.9.4 and Netscape 6.0…6.2.3
-
Old Moz：Mozilla 0.9.5 through 1.1 alpha and Mozilla 1.0
-
Moz & Safari & Opera 10 & IE10 & HTML5：Mozilla 1.0.1, Mozilla 1.1 beta and later, Firefox, Netscape 7 and later, Safari 0.9 and later, Opera 10 and later, Chrome, Konqueror 3.5, IE10, the HTML5 specified behavior
-
Opera 9.0：Opera 9.0…9.20
-
IE 8, IE 9 & Opera 9.5：IE 8 or IE 9 by default when there is noX-UA-Compatible override nor a Compatibility View override (“A” means the IE8 Almost Standards mode for IE8 and IE9 Almost Standards mode for IE9), Opera 7.5…8.54 and 9.5…9.6
-
IE 7 & Opera 7.10：Windows IE 7, IE 8 with Compatibility View enabled but withoutX-UA-Compatibleoverride (in this case “A” means the 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 (possibly also 3.1…3.2.1; I have not been able to confirm)
下面是一個表格，如果不能正常顯示，請參見原文：https://hsivonen.fi/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的怪癖模式。
附錄：IE8的模式選擇
開始選擇
-
X-UA-Compatible meta元素
-
IE=7: 使用 IE7 標準模式
-
IE=EmulateIE7: 參見 “怪癖模式或無模式 (兼容模式)”.
-
IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or absent or has script first: 參見 “X-UA-Compatible HTTP 頭”.
-
IE=8 or IE=Edge or IE=99 or IE=9.9: 參見 “近乎標準模式Doctype?”.
-
IE=5: 使用怪癖模式 (IE 5.5).
-
X-UA-Compatible HTTP 頭?
-
IE=7: 使用 IE7 標準模式
-
IE=EmulateIE7: 參見 “怪癖模式或無模式 (兼容模式)”.
-
IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or absent: 參見 “顯示所有互聯網站點...預設”.
-
IE=8 or IE=Edge or IE=99 or IE=9.9: 參見 “近乎標準模式Doctype?”.
-
IE=5: 使用怪癖模式 (IE 5.5).
-
怪癖模式或無模式 (兼容模式)
-
Yes: 使用怪癖模式 (IE 5.5).
-
No: 使用 IE7 標準模式
-
顯示所有互聯網站點...預設
-
Yes: 參見 “怪癖模式或無模式 (兼容模式)”.
-
No: 參見 “顯示所有內聯網站點...預設”.
-
顯示所有內聯網站點...預設
-
Yes: 參見“是否在內聯網區域”.
-
No: 參見“域名是否在微軟管理的列表中”.
-
是否在內聯網區域
-
Yes: 參見 “怪癖模式或無模式 (兼容模式)”.
-
No: 參見 “域名是否在微軟管理的列表中”.
-
域名是否在微軟管理的列表中
-
Yes: 參見 “怪癖模式或無模式 (兼容模式)”.
-
No: 參見 “是否被兼容模式的頁面嵌入”.
-
是否被兼容模式的頁面嵌入
-
Yes: 參見 “怪癖模式或無模式 (兼容模式)”.
-
No: 參見 “是否按下了兼容模式按鈕”.
-
是否按下了兼容模式按鈕
-
Yes: 參見 “怪癖模式或無模式 (兼容模式)”.
-
No: 參見 “怪癖模式或無模式 (IE8)”.
-
怪癖模式或無模式 (IE8)
-
Yes: 使用怪癖模式 (IE 5.5).
-
No: 參見 “近乎標準模式Doctype?”.
-
近乎標準模式Doctype?
-
Yes: 使用IE8近乎標準模式
-
No: 使用IE8標準模式
致謝
感謝Simon Pieters、Lachlan Hunt和Anne van Kesteren幫助我改正了各種Opera版本的模式表和他們的評論。感謝Simon Pieters制作了另一份IE8的流程圖。