知名瀏覽器對DOCTYPE模式的選擇機制

2020-03-24 18:37:38

字體：大中小

來源：轉載

供稿：網友

文檔范圍本文包括的模式轉換（mode switching）適用于Firefox和其他基于Gecko的瀏覽器，Safari、Chrome和其他基于Webkit的瀏覽器，Opera、 Konqueror、Mac版Internet Explorer、Windows版Internet Explorer和內嵌IE的瀏覽器。避免提及瀏覽器引擎的名字，取而代之的是使用該引擎最知名瀏覽器的名字。本文著重介紹模式的選擇機制，而不是記錄每個模式的確切行為。以下是各種不同的模式：內容類型為text/html的模式text/html內容的模式選擇取決于doctype嗅探（doctype sniffing，本文后面有討論）。在IE8中，模式也取決于其他因素。然而在IE8的默認情況下，那些不在微軟提供黑名單上的非局域網（non- intranet）站點的模式取決于文檔類型。再怎么強調每個瀏覽器中模式精確行為的不同也是不過分的，即使本文中進行了統一的討論。怪癖模式（Quirks Mode）怪癖模式中，為了避免破壞那些根據在20世紀90年代末流行的實踐創作的頁面，瀏覽器違反了現代的Web格式規范。不同的瀏覽器實現了不同的怪癖行為。Internet Explorer6、7和8中，怪癖模式有效地凍結在IE5.5 。其他瀏覽器中，怪癖模式是對準標準模式的少量偏移。如果正在創作新網頁，你應該符合相關的規范（特別是CSS2.1）且使用標準模式。標準模式（Standards Mode）標準模式中，瀏覽器嘗試給符合標準的文檔在規范上的正確處理達到在指定瀏覽器中的程度。不同的瀏覽器遵循不同的階段，所以標準模式也不是一個單一目標。 HTML5把這種模式叫非怪癖模式（no quirks mode）準標準模式（Almost Standards Mode） irefox、Safari、Chrome、Opera(從7.5開始)和IE8也有個叫準標準模式的模式，它按照傳統的做法來實現表格單元格的垂直尺寸而不是嚴格的遵照CSS2規范。Mac IE5、Windows IE6和7、Opera7.5以前版本和Konqueror無需準標準模式，因為它們至少沒有在各自的標準模式下嚴格遵循CSS2規范來實現表格單元格垂直尺寸。實際上，它們的標準模式更接近Mozilla的準標準模式而不是Mozilla的標準模式。 HTML5把這種模式叫著受限怪癖模式(limited quirks mode) 。 IE7模式 IE8有個模式主要是凍結了IE7標準模式的副本。其他瀏覽器沒有像這樣的模式，且該模式也未被HTML5指定。內容類型為application/xhtml+xml的模式（XML模式）Firefox、Safari、Chrome和Opera中，application/xhtml+xml HTTP內容類型（不是meta元素也不是doctype!）會觸發XML模式。在XML模式中，瀏覽器嘗試給XML文檔在規范上的正確處理達到在制定瀏覽器中的程度。IE6、7和8不支持application/xhtml+xml，Mac IE5也如此?；赪ebKit的Nokia S60 瀏覽器中，application/xhtml+xml HTTP內容類型不能觸發XML模式，因為在移動的圍墻花園（mobile walled gardens）中關注點是對不規范內容的兼容性。（舊式的移動瀏覽器無法使用真正的XML解析器，因為不規范內容已被標記為XML。）由于沒有充分地測試Konqueror，我無法確切說出在這個瀏覽器中會發生什么。非Web模式（Non-Web Modes）某些引擎擁有的模式與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嗅探（也叫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）和字符。文檔類型聲明位于文檔的根元素開始標簽之前。選擇doctypetext/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也會觸發標準模式，且10歲大的HTML4.01有效定義是穩定的。請確保在Firefox、Safari、Chrome、 Opera9或Opera10中測試圖像對齊。在Internet Explorer中測試圖像對齊是不足夠的，無論如何請確保在IE8中也進行了測試。要使用標準模式，但仍要驗證不推薦標記或在表格布局中使用切片圖像且不想去修復它們。 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd 它會觸發準標準模式（和老掉牙的Mozilla中的完全標準模式full Standards mode）。請注意，如果以后移植到HTML5上，基于利用表格實現的切片圖像的布局可能會被破壞（且完整標準模式也如此）。故意要使用怪癖模式沒有doctype。請別這樣做。故意為怪癖模式所做的設計將會困擾你，在將來你的同事或繼任者甚至沒有人關心Windows IE6（Netscape4.x和IE5已經沒有人關心了）。為怪癖模式設計是個壞主意。相信我。如果你想依舊支持Windows IE6，對它做一個特別的hack使用條件注釋比使其他瀏覽器退步到怪癖模式好。我不推薦任何的XHTML doctype，因為XHTML被用作text/html被認為是有害的。無論如何，如果你選擇使用XHTML doctype，請注意XML聲明會使IE6（但不是IE7?。┯|發怪癖模式。application/xhtml+xml對application/xhtml+xml的簡單指南是絕不使用doctype。該方式下的網頁不是嚴格一致的XHMTL1.0，但這并不重要。（請看后面的附錄）IE8 并發癥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標準模式。模式的選擇取決于來自幾個方面的數據：doctype、meta元素、HTTP頭、來自微軟的定期下載數據、局域網域、用戶所做設置、局域網管理員所做設置、父框架的模式（如果有）和地址欄兼容視圖按鈕被用戶觸發。（對于嵌入該引擎的其他應用，模式也取決于嵌入的應用。）幸運的是如果出現下列情況，IE8大體上會像其他瀏覽器一樣使用doctype嗅探：作者沒有設置X-UA-Compatible HTTP頭作者沒有設置X-UA-Compatible meta標簽微軟沒有在黑名單中放置該站點的域名局域網管理員沒有把該站點放置到黑名單上用戶沒有按下兼容視圖按鈕（Compatibility View button） (或以其他方式添加到某個特定的用戶黑名單中) 該站點不在局域網域中用戶沒有選擇在IE7中顯示所有站點頁面沒有通過frame嵌入到兼容模式的頁面中上述除兩個關于X-UA-Compatible的情況外，IE8像IE7一樣執行doctype嗅探。IE7仿真（ IE7 emulation）叫兼容視圖。在 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標簽的：你的域名沒有在微軟的黑名單上，你更關注是沒有瀏覽器專屬的令人討厭的東西而不是確保用戶無法回退去呈現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中破壞首先，在你的頁面包含后面的meta元素（它在HTML5中是非法的）（在任何腳本元素前），或者設置后面的HTTP頭： X-UA-Compatible: IE=EmulateIE7，然后修復你的站點不依賴非標準的IE7行為和遷移到IE=Edge。 Eric Meyer在使用正確doctype中寫的關于Mac IE5的模式 Mozilla的doctype嗅探 by David Baron Lance Silver在IE6中的CSS增強中討論了在Windows IE6中的模式和doctype嗅探 Opera9的doctype轉換 Faruk Ate 的IE8和X-UA-Compatible解決方案補遺：對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驗證器會說結果僅僅是暫時有效?；蚋玫氖牵憧梢杂梅艑扤G驗證，它不會污染模式引用的文檔。)為了嗅探而要求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關于此事的文章 comp.text.sgml 附錄：text/html中一些doctype的處理方式下表中，怪癖模式、標準模式和準標準分別表示為Q、S和A。當瀏覽器僅有兩種模式時，如果表格單元格的行高和Mozilla的標準模式表現一致時，標準模式標記為 S ，如果表格單元格的行高和Mozilla的準標準模式表現一致時，則標記為 A 。請注意使用XML內容模型提供服務的XHTML在XML模式下渲染。本表的目的并不是說表中所有的doctype都是新建頁面的合理選擇。本表的目的是為了展示我的推薦是依據什么樣的數據。下列的簡寫符號是用于列標題：NS6 Mozilla 0.6 0.9.4 和 Netscape 6.0 6.2.3 Old Moz Mozilla 0.9.5 到 1.1 alpha 和 Mozilla 1.0 Moz Safari Opera 10 HTML5 Mozilla 1.0.1, Mozilla 1.1 beta和更高版本, Firefox 到 Netscape 7, Safari 0.9 到 Safari 4.0 beta, Opera 10, Chrome, Konqueror 3.5, HTML5指定的行為 Opera 9.0 Opera 9.0 9.20 IE 8 Opera 9.5 無 X-UA-Compatible和兼容模式覆蓋的默認IE8（該情況下 A 意味著IE8準標準模式）、 Opera 7.5 8.54 和 9.5 9.6 IE 7 Opera 7.10 IE7、兼容模式且無X-UA-Compatible覆蓋的IE8（這種情況下 A 意味IE7模式）和Opera 7.10 7.23 IE 6 Opera 7.0 Windows IE 6 和 Opera 7.0 7.03 Mac IE 5 Mac IE 5.0 5.2.3 Konq 3.2 Konqueror 3.2.2 3.3 (也可能包括 3.1 3.2.1; 我尚未確定)
感謝Simon Pieters、Simon Pieters和Anne van Kesteren幫助我改正了各種Opera版本的模式表和他們的評論。感謝Simon Pieters制作了另一份IE8的流程圖。
html教程

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。

上一篇：詳解瀏覽器渲染流程

下一篇：瀏覽器中5種常用的事件解析