本文包括的模式轉換(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)文檔類型聲明包含(被空白分開)“<!DOCTYPE”字符串,根元素(“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 Stachowiak的評論。)
IE8有4種模式:IE5.5怪癖模式、IE7標準模式、IE8 準標準模式 和IE8標準模式。模式的選擇取決于來自幾個方面的數據:doctype、meta元素、HTTP頭、來自微軟的定期下載數據、局域網域、用戶所做設置、局域網管理員所做設置、父框架的模式(如果有)和地址欄兼容視圖按鈕被用戶觸發。(對于嵌入該引擎的其他應用,模式也取決于嵌入的應用。)
幸運的是如果出現下列情況,IE8大體上會像其他瀏覽器一樣使用doctype嗅探:
上述除兩個關于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標簽的:
請不要把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關于此事的文章 comp.text.sgml
下表中,怪癖模式、標準模式和準標準分別表示為Q、S和A。當瀏覽器僅有兩種模式時,如果表格單元格的行高和Mozilla的標準模式表現一致時,標準模式標記為“S”,如果表格單元格的行高和Mozilla的準標準模式表現一致時,則標記為“A”。
請注意使用XML內容模型提供服務的XHTML在XML模式下渲染。
本表的目的并不是說表中所有的doctype都是新建頁面的合理選擇。本表的目的是為了展示我的推薦是依據什么樣的數據。
下列的簡寫符號是用于列標題:
Doctype | NS6 | Old Moz | Moz & Safari & Opera10 & HTML5 | Opera9.0 | IE8 & Opera9.5 | IE7 & Opera7.10 | IE6 & Opera7.0 | Mac IE5 | Konq3.2 |
---|---|---|---|---|---|---|---|---|---|
None | Q | Q | Q | Q | Q | Q | Q | Q | Q |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> | Q | Q | Q | Q | Q | Q | Q | Q | Q |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> | S | S | S | S | S | A | A | A | A |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> | S | S | S | S | S | A | A | Q | A |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/html4/strict.dtd"> | S | S | S | S | S | A | A | A | A |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> | S | S | S | S | S | A | A | A | A |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> | Q | Q | Q | Q | Q | Q | Q | Q | Q |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> | Q | Q | Q | Q | Q | Q | Q | Q | Q |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | S | S | A | A | A | A | A | A | Q |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
| Q | S | A | A | A | A | A | A | Q |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | Q | Q | Q | Q | A | A | A | A | Q |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> | S | S | S | S | S | A | A | A | A |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> | S | S | S | S | S | A | A | A | A |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> | S | S | S | S | S | A | A | A | A |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> | S | S | A | A | A | A | A | A | Q |
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> | S | S | S | S | S | A | Q | A | Q |
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> | S | S | S | S | S | A | Q | A | Q |
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> | S | S | S | S | S | A | Q | A | Q |
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
| S | S | A | A | A | A | Q | A | Q |
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN"> | Q | S | S | Q | Q | Q | Q | Q | Q |
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN"> | Q | S | S | S | S | A | A | A | Q |
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:1999//DTD HTML//EN"> | S | S | S | Q | Q | Q | Q | Q | Q |
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:1999//DTD HyperText Markup Language//EN"> | S | S | S | S | S | A | A | A | Q |
<!DOCTYPE html> | Q | S | S | S | S | A | A | A |
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的怪癖模式。
這些步驟都可以通過PDF和PNG格式的流程圖看到。
感謝Simon Pieters、Simon Pieters和Anne van Kesteren幫助我改正了各種Opera版本的模式表和他們的評論。感謝Simon Pieters制作了另一份IE8的流程圖。
新聞熱點
疑難解答