原文： http://www.alistapart.com/articles/beyonddoctype

作者：Aaron Gustafson

譯者：zhaozy in 3user.com

轉(zhuǎn)載請注明作者和譯者信息,謝謝!

進步總是要有代價的. 對網(wǎng)頁瀏覽器來說, 由于開發(fā)者像是宣傳真理一樣一些編輯器和瀏覽器(特別是Internet Explorer), 用戶們?yōu)榇嘶ㄙM很多的成本. 而當(dāng)這個瀏覽器推出了一個新版本, 然后又修正了之前版本的一些錯誤和對規(guī)范的誤解(或是引入了新的), 或是以任何方式改變行為時. 站點突然崩潰了, 然后我們的客戶, 我們的老板和用戶們都感覺到非常的不開心.

我們也許可以花上一段時間來解釋為什么我們的網(wǎng)站壞了, 但是如果他們沒有被破.壞那不是更好嗎? 一點點背景介紹

在成功的放出了更好的支持CSS的Internet Explorer 7的動力下, IE團隊開始在一個嶄新的渲染引擎(更好的遵照CSS 2.1規(guī)范)上開始進行IE 8的開發(fā)工作. 在他們的努力下, 瀏覽器已經(jīng)可以相當(dāng)精確地表現(xiàn)出 "Acid2 test" (http://webstandards.org/action/acid2/) . 這些你跟進的消息, 意味著IE將很快的支持生成內(nèi)容和數(shù)據(jù)的URLs, 而且經(jīng)確認, hasLayout會被永遠取消. 它的表現(xiàn)結(jié)果會讓其他通過Acid2測試的瀏覽器們進行投票(包括: Safari, iCab, Konqueror, and Opera. Firefox3也已經(jīng)通過了Acid2測試,但是在文章編寫的時候還沒有放出.)

在新引擎的開發(fā)過程中, IE團隊謹記IE 7放出后的反面評價. 一些web標(biāo)準(zhǔn)的狂熱者甚至是一部分微軟的崇拜者感覺到在"IE7中他們做得還不夠 (程序缺陷的修正和CSS支持的改進上)". 但是有很大的一群開發(fā)者在感到疑惑, 因為他們的網(wǎng)站在IE6中表現(xiàn)的很完美, 但是到了IE7就完全崩潰了. web標(biāo)準(zhǔn)倡導(dǎo)者 Roger Johanssen 在他的博客中提出了 "頁面被破壞的三大原因" (http://www.456bereastreet.com/archive/200611/three_reasons_sites_break_in_internet_explorer_7/), 這些都驅(qū)使大家去改善對標(biāo)準(zhǔn)的支持. IE開發(fā)團隊發(fā)現(xiàn)了第四點: 文檔類型轉(zhuǎn)換(DOCTYPE switch), 一個啟用現(xiàn)代CSS布局的核心技術(shù)在標(biāo)志兼容性上有致命的缺陷. 文檔類型轉(zhuǎn)換器失效了

回到1998年, Todd Fahrner 的 "came up with a toggle(http://web.archive.org/web/20030212115103/http://www.geocrawler.com/archives/list-name.mbox/123/1998/7/0/1037920/)" 方法能允許一個瀏覽器提供兩套渲染模式: 一是給期許遵守標(biāo)準(zhǔn)的開發(fā)者的, 另一個是給其他所有人的. 這個觀點精辟簡單. 當(dāng)用戶端代理遇到對當(dāng)前HTML標(biāo)準(zhǔn)的Doctype聲明良好定義的文檔時(也就是 HTML2 不會取消它), 創(chuàng)作者就會知道她在做什么, 并且用"標(biāo)準(zhǔn)"模式渲染這個頁面(用W3C的盒模型元素布局). 但是在沒有Doctype或者定義了不正確Doctype時, 文檔會被用"Quirks" 模式渲染, 也就是說, 用windows版的IE5.X的非標(biāo)準(zhǔn)盒模型進行元素布局.

這個概念在兩年后的Mac版的IE上被首次運用, 這種方法很快的被其他瀏覽器制.造者采用, 意識到標(biāo)準(zhǔn)的開發(fā)者會在他們的文檔中包含正確的Doctype, 這樣做他們的部分在瀏覽器根據(jù)規(guī)范進行渲染時就不需要額外的工作了. 不注意標(biāo)準(zhǔn)的開發(fā)者很幸福的, 他們自己沒有發(fā)現(xiàn), 他們以及他們的工具都沒有為他們插.入正確的Doctype, 但是他們的文檔在瀏覽器中被特殊對待了.

不幸的是, 因為兩個關(guān)鍵問題, 為配合廣大的呼聲,Doctype不可能持續(xù)充當(dāng)標(biāo)準(zhǔn)模式的轉(zhuǎn)換器了:

1. A List Apart和Web標(biāo)準(zhǔn)項目的推廣, 善良的編輯器開發(fā)者開始為他們的工具生成的標(biāo)記中插.入有效的,完整的Doctype. IE6的渲染行為有5年沒有更新了, 這讓大部分開發(fā)者認為這個引擎是正確的, 并且不太會發(fā)生改變了.

這兩種情況破壞了Doctype的轉(zhuǎn)換, 因為它有致命的缺陷: 使用有效的Doctype意味著你明白你在通過web標(biāo)準(zhǔn)做什么, 你希望獲得更正確的渲染, 但是我們怎么知道它失敗了呢? 當(dāng)IE 7降臨的時候, 網(wǎng)站們變樣了.

當(dāng)然, 就像Roger指出的那樣, 一些被破壞的網(wǎng)站是使用IE6特有的CSS Hack(通常不會有提供選擇的機會). 但是發(fā)生這樣的慘劇是因為他們的開發(fā)者只在IE6當(dāng)中測試他們的頁面, 或者他們只關(guān)心在IE6中, 他們的網(wǎng)站是什么樣的. 因為他們?yōu)槭褂猛活悶g覽器的族群開發(fā)網(wǎng)站(比如說公司的內(nèi)部網(wǎng)). 現(xiàn)在當(dāng)然, 你可以只是聳聳肩然后說, 這是被證明是IE6的錯, 但是這些開發(fā)者應(yīng)該知道的更多, 但是你會忽略一個事實, 就是這些開發(fā)者們從來沒有明確的選擇 "standards mode", 甚至他們知道有這么個模式存在.

Chris Wilson, Internet Explorer的平面架構(gòu)師, 經(jīng)常提到的一個在IE上開發(fā)的核心原則: IE團隊做出的任何選擇的目的絕對不是 "破壞網(wǎng)頁". 可悲的是, IE 7卻讓去多人面對這個事實. Microsoft不愿意造成第二次錯誤, MicroSoft開始進入Web標(biāo)準(zhǔn)項目(我是其中成員之一), 以及其他幾個有標(biāo)準(zhǔn)意識的開發(fā)者, 向我們尋求幫助去尋找一個允許開發(fā)者自主選擇支持web標(biāo)準(zhǔn)的好辦法. 最終的目標(biāo)是找到一種可以比Doctype選擇器更直接清楚的方法, 可以運用到任何瀏覽器中, 不只是IE. 美好的未來

在去年召開的SXSW中, 我有幸看到了紐約公共圖書館的Carrie Bickner(同時是ALA的出版者Jeffrey Zeldman的妻子)領(lǐng)導(dǎo)的神奇的議題. "保存我們的數(shù)字遺產(chǎn)以及我們的個人收藏", 討論圖書館和個人在維護數(shù)字檔案時遇到的問題. 大部分的問題源自文件格式和應(yīng)用程序的進步: 例如 Microsoft Office 2007, 它不能可靠的展現(xiàn)一個本來可以展現(xiàn)的word 1.0的文檔. 這個議題讓我想到了網(wǎng)頁從建立開始會有怎樣的改變, 以及它們在web標(biāo)準(zhǔn)進步的同時又會怎樣的改變.

作為一個web標(biāo)準(zhǔn)的支持者, 我想看到的是瀏覽器在提供新的支持的時候不斷的為執(zhí)行標(biāo)準(zhǔn)化而改進. 同時我也看到了保護我們曾經(jīng)辛辛苦苦建立的基于table布局的網(wǎng)站的重要性. 當(dāng)然, 大部分通過 " Wayback Machine " 存在的錯誤因為Doctype轉(zhuǎn)換器仍然可以很好的為他們服務(wù)而暫時沒有遭受到打擊, 但是那些讓IE 6執(zhí)行"standards"模式的網(wǎng)站呢? 我也都知道, 在很多案例下, IE 7 也不能完全的渲染它們. 這是不是意味著我們有必要保留一份IE 6的備份在手邊, 為了瀏覽這個網(wǎng)頁達到的效果如同創(chuàng)作者想要的那樣? 這就是很多圖書館為了瀏覽古老的文件所做的事情. 在IE 8的時代, 我們同樣會面對這些潛在的問題, 用IE 7的渲染引擎生成的正常的文檔會不會在IE 8中變了形, 怎么來解決這個問題呢?

#p# 針對瀏覽器版本

在理想的世界里, 當(dāng)然, 所有的規(guī)范都將是完美的, 而且他們在用戶端將直接的完美的被執(zhí)行. 在更實際的理想世界里, 瀏覽器廠商應(yīng)該為新用戶直接提供符合標(biāo)準(zhǔn)的更新, 用戶可以不費吹灰之力的使用這些最新版本的瀏覽器. 如果是這樣, 我們這些開發(fā)者就可以用最新的最偉大的技術(shù)去構(gòu)建網(wǎng)站和應(yīng)用程序, 而不用考慮向下兼容的問題. 但是我們都知道, 現(xiàn)實世界離這個狀態(tài)還差不太遠.

標(biāo)準(zhǔn)總是在斷斷續(xù)續(xù)的開發(fā)和改進, 有時會花上幾年時間, 提出他們認為的"推薦"狀態(tài). 但是瀏覽器發(fā)行的周期是被產(chǎn)品管理和市場的關(guān)注(安全性, 功能, 速度)左右的, 很少有能和標(biāo)準(zhǔn)規(guī)范的定稿相符合的, 甚至當(dāng)瀏覽器開發(fā)商他們自己很積極的用非常標(biāo)準(zhǔn)的方法進行開發(fā), 但是用戶們, 特別是同樣組織背景的用戶, 往往是很懶于更新他們的瀏覽器的.

我們面對所有這些因素, 網(wǎng)站開發(fā)者們在制作網(wǎng)站時都會有點不是滋味, 我們怎么確保讓瀏覽器渲染的結(jié)果繼續(xù)保持我們想要讓他們呈現(xiàn)的樣子?

我們可以指定我們想要用的語言的版本, 就像是 CSS 2.1或者JavaScript 1.5. 但是不幸的是, 瀏覽器渲染通常只會執(zhí)行規(guī)范的一部分, 而且在瀏覽器之間對規(guī)范的解釋也會存在差異. 所以任何兩個不同時代的瀏覽器會對CSS有完全不同的渲染, 或者對一個同一個表單控制器觸發(fā)不同的事件.

因為這些搗亂在工作中出現(xiàn), 我們真得只剩下一種選擇, 讓我們今天創(chuàng)建的網(wǎng)站在未來五年中看起來就像今天一樣: 定義一個這個網(wǎng)站建立并測試過的瀏覽器版本列表, 然后要求瀏覽器制.造商用一種方法執(zhí)行原先的渲染和腳本解釋引擎來讓這個網(wǎng)站看上去和建立的時候一樣, 在未來有較好的表現(xiàn).

這就是為什么我們團隊決定推薦IE8, 然后我們也希望在其他瀏覽器中也能很好的執(zhí)行. 保持語法的簡煉

確保瀏覽器的 "版本目標(biāo)" 能較容易地被開發(fā)者接受的一個關(guān)鍵是能夠用手動或是編輯器簡單的執(zhí)行. 我們考慮了很多語法方案, 包括 條件注釋型語法, 按XML Porlog方式的處理指令, 又或是HTML檔案, 比如那些被微格式區(qū)域所采用的, 但是幾乎都沒有Meta元素來的更適合這個工作.

用一個簡單的Meta聲明, 我們能指定在IE8中的渲染引擎來使用, 例如, 插.入這樣一段代碼

<meta http-equiv="X-UA-Compatible" content="IE=8" />

在文檔的head區(qū)域里, 可以讓IE 8渲染用最新的標(biāo)準(zhǔn)模式渲染這個頁面, 這個語法可以很容易的擴展到其他瀏覽器上:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

為了加快處理這個固定指令的速度, 我們要像處理字符編碼信息meta時運用的優(yōu)先級機制引入到這個版本目標(biāo)meta元素上, 為了讓它起到作用, meta元素必須放到文檔的head里, 并且盡可能的靠近頂部. 它可以讓其他的meta元素或title元素更優(yōu)先, 但是一定要在其他的元素的上面, 并且不同通過JavaScript把它加進DOM中.

大家注意到, 我們在這里用到的meta元素是HTTP-equivalent類型的, 這就意味著我們可以用下面這種方法設(shè)置服務(wù)器的頭文件來獲得同樣的效果.

X-UA-Compatible: IE=8;FF=3;OtherUA=4

我們也能同時使用兩種方法, 例如我們可能通過使用頭文件的方法設(shè)置一條基線來全局定義一整個網(wǎng)站, 然后用meta的方法在單個的頁面覆蓋頭文件的設(shè)置.

#p# 逐步加強(progressive enhancement)哪去了?

使用了這個能把你的網(wǎng)站為某個瀏覽器版本進行鎖定是相當(dāng)神奇的, 這樣你的網(wǎng)站在將來也表現(xiàn)出不錯的可用性, 但是這樣做會不會破壞了逐步加強的概念了呢? 是不是我們都要改變我們建站的方法了呢? 我們能不能繼續(xù)自動應(yīng)用新的CSS屬性, 它們會變得可用嗎? 這是當(dāng)我們還是討論"版本目標(biāo)"的可行性時我的許多疑問中的幾個.

例如, 讓我們假設(shè) IE 8不再繼續(xù)支持生成內(nèi)容(generated content) - 如果Acid2公布任何跡象的話, 它會, 請容忍我把它作為一個例子: 我們在"鎖定了" IE 8 的網(wǎng)站上使用生成內(nèi)容的話, 另外除了IE之外的現(xiàn)代瀏覽器會渲染生成內(nèi)容, 但是就算是IE 9又支持了生成內(nèi)容, 有人用IE 9訪問這個網(wǎng)站的話, 還是會看不到生成內(nèi)容, 因為這個網(wǎng)站被鎖定在 IE 8 了. 如果把這個網(wǎng)站的鎖定升級到IE 9, 那么生成內(nèi)容就顯示出來了, 這是和逐步加強相違背的.

失去了逐步加強這個特點著實讓我頭痛, 但是這種行為是會發(fā)生的最好的事情了, 尤其是當(dāng)網(wǎng)站是面向大眾的. 畢竟, 我們不應(yīng)該去假設(shè)瀏覽器在將來會是什么樣. 如果 IE 9 的一個更改破壞了我們網(wǎng)站的布局或是我們的script中的一個功能的話, 這可能對于我們的用戶來說會災(zāi)難性的, 并且會給我們的團隊帶來瘋狂的混亂 - 在新瀏覽器下修復(fù)這個網(wǎng)站的功能(我們已經(jīng)上了太多條船了). 針對版本給我們團隊一種決定什么時候支持新瀏覽器的能力, 更重要的是, 給我們足夠的時間作出必要的調(diào)整來支持新瀏覽器.

針對版本意味著逐步加強的終結(jié)嗎? 在這個問題上, 不是. 首先, 我們?nèi)匀辉谖磥淼膸啄陜?nèi)會處理遺留 / 預(yù)先鎖定瀏覽器, 并逐步加強, 這是個行之有效的方法將在他們中間逐步支持不同階段的CSS和JavaScript. 此外, 還有一個地方提供IE瀏覽器的樣式和腳本的補丁, 雖然我們希望隨著時間的過去這樣的需求會越來越少. 最后, 用逐步加強技術(shù)撰寫JavaScript仍舊會很大程度上減少為了準(zhǔn)備支持新瀏覽器而作出的重構(gòu)時間. 技巧延伸: 生活在"邊緣"

對于那些樂意拋棄嚴謹?shù)膽B(tài)度的, 不計后果的, 或者其他不計后果的放任的口語化編程習(xí)慣, IE 會支持一個關(guān)鍵詞: "edge:"

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

這個選項, 雖然我們極力阻止, 但是這會讓一個網(wǎng)站把版本鎖定在所發(fā)布的最新的IE瀏覽器上. 這比設(shè)定一個不切實際的 IE=1000要來的清晰一點, 是吧? 但是從版本目標(biāo)的所有優(yōu)點來說, "edge"值除了實驗性的網(wǎng)站外都是不切實際的吧. 那是因為就算是 Eric Meyer也沒辦法預(yù)料在新版本瀏覽器中會有什么布局或是腳本的缺陷. 對未來的希望

多年來, 我們設(shè)計師和開發(fā)者都渴望著有種方法可以讓我們的網(wǎng)站更可靠. 除了為撰寫跨平臺的樣式和腳本而頭痛, 我們還必須處理一些由于新瀏覽器的發(fā)布而造成的一些不可預(yù)料的損壞. 向客戶, 老板和用戶解釋這個不可預(yù)期的損壞從來不是個開心的差事. 但是, 通過IE 8的版本目標(biāo)的介紹, 讓隧道的盡頭出現(xiàn)了一點光亮. 我, 作為其中一個, 希望其他的瀏覽器渲染都一起參加Microsoft來貫徹這個方法.

個人并不是很贊同,這位標(biāo)準(zhǔn)推行者并沒有把目標(biāo)放在如何讓標(biāo)準(zhǔn)的推行成為要務(wù),卻又推出了IE 8中的version targeting功能,只能說,IE真的會慣壞一批開發(fā)者,不規(guī)范的編碼,和大量使用私有方法,難道又要浮上水面嗎?很難的推行了標(biāo)準(zhǔn)好些年,又準(zhǔn)備回到那個混亂的年代了么...IE6 - IE7的轉(zhuǎn)變造成的大范圍災(zāi)難說到底應(yīng)該責(zé)怪誰呢? 不是M$自己我行我素的精神么?

PS. 這篇很像是M$的軟文...

過陣子再翻譯下Eric Meyer跳出來反對這種理論的文章, 理論性的爭論還是相當(dāng)精彩的