原文： http://www.alistapart.com/articles/beyonddoctype
作者：aaron gustafson
譯者：zhaozy in 3user.com
轉載請注明作者和譯者信息,謝謝!
進步總是要有代價的. 對網頁瀏覽器來說, 由于開發者像是宣傳真理一樣的拍著胸部擔保著一些編輯器和瀏覽器(特別是internet explorer), 用戶們為此花費很多的成本. 而當這個瀏覽器推出了一個新版本, 然后又修正了之前版本的一些錯誤和對規范的誤解(或是引入了新的), 或是以任何方式改變行為時. 站點突然崩潰了, 然后我們的客戶, 我們的老板和用戶們都感覺到非常的不開心.
我們也許可以花上一段時間來解釋為什么我們的網站壞了, 但是如果他們沒有被破壞那不是更好嗎?
在成功的放出了更好的支持css的internet explorer 7的動力下, ie團隊開始在一個嶄新的渲染引擎(更好的遵照css 2.1規范)上開始進行ie 8的開發工作. 在他們的努力下, 瀏覽器已經可以相當精確地表現出 "acid2 test" (http://webstandards.org/action/acid2/) . 這些你跟進的消息, 意味著ie將很快的支持生成內容和數據的urls, 而且經確認, haslayout會被永遠取消. 它的表現結果會讓其他通過acid2測試的瀏覽器們進行投票(包括: safari, icab, konqueror, and opera. firefox3也已經通過了acid2測試,但是在文章編寫的時候還沒有放出.)
在新引擎的開發過程中, ie團隊謹記ie 7放出后的反面評價. 一些web標準的狂熱者甚至是一部分微軟的崇拜者感覺到在"ie7中他們做得還不夠 (程序缺陷的修正和css支持的改進上)". 但是有很大的一群開發者在感到疑惑, 因為他們的網站在ie6中表現的很完美, 但是到了ie7就完全崩潰了. web標準倡導者 roger johanssen 在他的博客中提出了 "頁面被破壞的三大原因" (http://www.456bereastreet.com/archive/200611/three_reasons_sites_break_in_internet_explorer_7/), 這些都驅使大家去改善對標準的支持. ie開發團隊發現了第四點: 文檔類型轉換(doctype switch), 一個啟用現代css布局的核心技術在標志兼容性上有致命的缺陷.
回到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/)" 方法能允許一個瀏覽器提供兩套渲染模式: 一是給期許遵守標準的開發者的, 另一個是給其他所有人的. 這個觀點精辟簡單. 當用戶端代理遇到對當前html標準的doctype聲明良好定義的文檔時(也就是 html2 不會取消它), 創作者就會知道她在做什么, 并且用"標準"模式渲染這個頁面(用w3c的盒模型元素布局). 但是在沒有doctype或者定義了不正確doctype時, 文檔會被用"quirks" 模式渲染, 也就是說, 用windows版的ie5.x的非標準盒模型進行元素布局.
這個概念在兩年后的mac版的ie上被首次運用, 這種方法很快的被其他瀏覽器制造者采用, 意識到標準的開發者會在他們的文檔中包含正確的doctype, 這樣做他們的部分在瀏覽器根據規范進行渲染時就不需要額外的工作了. 不注意標準的開發者很幸福的, 他們自己沒有發現, 他們以及他們的工具都沒有為他們插入正確的doctype, 但是他們的文檔在瀏覽器中被特殊對待了.
不幸的是, 因為兩個關鍵問題, 為配合廣大的呼聲,doctype不可能持續充當標準模式的轉換器了:
這兩種情況破壞了doctype的轉換, 因為它有致命的缺陷: 使用有效的doctype意味著你明白你在通過web標準做什么, 你希望獲得更正確的渲染, 但是我們怎么知道它失敗了呢? 當ie 7降臨的時候, 網站們變樣了.
當然, 就像roger指出的那樣, 一些被破壞的網站是使用ie6特有的css hack(通常不會有提供選擇的機會). 但是發生這樣的慘劇是因為他們的開發者只在ie6當中測試他們的頁面, 或者他們只關心在ie6中, 他們的網站是什么樣的. 因為他們為使用同一類瀏覽器的族群開發網站(比如說公司的內部網). 現在當然, 你可以只是聳聳肩然后說, 這是被證明是ie6的錯, 但是這些開發者應該知道的更多, 但是你會忽略一個事實, 就是這些開發者們從來沒有明確的選擇 "standards mode", 甚至他們知道有這么個模式存在.
chris wilson, internet explorer的平面架構師, 經常提到的一個在ie上開發的核心原則: ie團隊做出的任何選擇的目的絕對不是 "破壞網頁". 可悲的是, ie 7卻讓去多人面對這個事實. microsoft不愿意造成第二次錯誤, microsoft開始進入web標準項目(我是其中成員之一), 以及其他幾個有標準意識的開發者, 向我們尋求幫助去尋找一個允許開發者自主選擇支持web標準的好辦法. 最終的目標是找到一種可以比doctype選擇器更直接清楚的方法, 可以運用到任何瀏覽器中, 不只是ie.
在去年召開的sxsw中, 我有幸看到了紐約公共圖書館的carrie bickner(同時是ala的出版者jeffrey zeldman的妻子)領導的神奇的議題. "保存我們的數字遺產以及我們的個人收藏", 討論圖書館和個人在維護數字檔案時遇到的問題. 大部分的問題源自文件格式和應用程序的進步: 例如 microsoft office 2007, 它不能可靠的展現一個本來可以展現的word 1.0的文檔. 這個議題讓我想到了網頁從建立開始會有怎樣的改變, 以及它們在web標準進步的同時又會怎樣的改變.
作為一個web標準的支持者, 我想看到的是瀏覽器在提供新的支持的時候不斷的為執行標準化而改進. 同時我也看到了保護我們曾經辛辛苦苦建立的基于table布局的網站的重要性. 當然, 大部分通過 " wayback machine " 存在的錯誤因為doctype轉換器仍然可以很好的為他們服務而暫時沒有遭受到打擊, 但是那些讓ie 6執行"standards"模式的網站呢? 我也都知道, 在很多案例下, ie 7 也不能完全的渲染它們. 這是不是意味著我們有必要保留一份ie 6的備份在手邊, 為了瀏覽這個網頁達到的效果如同創作者想要的那樣? 這就是很多圖書館為了瀏覽古老的文件所做的事情. 在ie 8的時代, 我們同樣會面對這些潛在的問題, 用ie 7的渲染引擎生成的正常的文檔會不會在ie 8中變了形, 怎么來解決這個問題呢?
|||
在理想的世界里, 當然, 所有的規范都將是完美的, 而且他們在用戶端將直接的完美的被執行. 在更實際的理想世界里, 瀏覽器廠商應該為新用戶直接提供符合標準的更新, 用戶可以不費吹灰之力的使用這些最新版本的瀏覽器. 如果是這樣, 我們這些開發者就可以用最新的最偉大的技術去構建網站和應用程序, 而不用考慮向下兼容的問題. 但是我們都知道, 現實世界離這個狀態還差不太遠.
標準總是在斷斷續續的開發和改進, 有時會花上幾年時間, 提出他們認為的"推薦"狀態. 但是瀏覽器發行的周期是被產品管理和市場的關注(安全性, 功能, 速度)左右的, 很少有能和標準規范的定稿相符合的, 甚至當瀏覽器開發商他們自己很積極的用非常標準的方法進行開發, 但是用戶們, 特別是同樣組織背景的用戶, 往往是很懶于更新他們的瀏覽器的.
我們面對所有這些因素, 網站開發者們在制作網站時都會有點不是滋味, 我們怎么確保讓瀏覽器渲染的結果繼續保持我們想要讓他們呈現的樣子?
我們可以指定我們想要用的語言的版本, 就像是 css 2.1或者javascript 1.5. 但是不幸的是, 瀏覽器渲染通常只會執行規范的一部分, 而且在瀏覽器之間對規范的解釋也會存在差異. 所以任何兩個不同時代的瀏覽器會對css有完全不同的渲染, 或者對一個同一個表單控制器觸發不同的事件.
因為這些搗亂在工作中出現, 我們真得只剩下一種選擇, 讓我們今天創建的網站在未來五年中看起來就像今天一樣: 定義一個這個網站建立并測試過的瀏覽器版本列表, 然后要求瀏覽器制造商用一種方法執行原先的渲染和腳本解釋引擎來讓這個網站看上去和建立的時候一樣, 在未來有較好的表現.
這就是為什么我們團隊決定推薦ie8, 然后我們也希望在其他瀏覽器中也能很好的執行.
確保瀏覽器的 "版本目標" 能較容易地被開發者接受的一個關鍵是能夠用手動或是編輯器簡單的執行. 我們考慮了很多語法方案, 包括 條件注釋型語法, 按xml porlog方式的處理指令, 又或是html檔案, 比如那些被微格式區域所采用的, 但是幾乎都沒有meta元素來的更適合這個工作.
用一個簡單的meta聲明, 我們能指定在ie8中的渲染引擎來使用, 例如, 插入這樣一段代碼
<meta http-equiv="x-ua-compatible" content="ie=8" />
在文檔的head區域里, 可以讓ie 8渲染用最新的標準模式渲染這個頁面, 這個語法可以很容易的擴展到其他瀏覽器上:
<meta http-equiv="x-ua-compatible" content="ie=8;ff=3;otherua=4" />
為了加快處理這個固定指令的速度, 我們要像處理字符編碼信息meta時運用的優先級機制引入到這個版本目標meta元素上, 為了讓它起到作用, meta元素必須放到文檔的head里, 并且盡可能的靠近頂部. 它可以讓其他的meta元素或title元素更優先, 但是一定要在其他的元素的上面, 并且不同通過javascript把它加進dom中.
大家注意到, 我們在這里用到的meta元素是http-equivalent類型的, 這就意味著我們可以用下面這種方法設置服務器的頭文件來獲得同樣的效果.
x-ua-compatible: ie=8;ff=3;otherua=4
我們也能同時使用兩種方法, 例如我們可能通過使用頭文件的方法設置一條基線來全局定義一整個網站, 然后用meta的方法在單個的頁面覆蓋頭文件的設置.
|||
使用了這個能把你的網站為某個瀏覽器版本進行鎖定是相當神奇的, 這樣你的網站在將來也表現出不錯的可用性, 但是這樣做會不會破壞了逐步加強的概念了呢? 是不是我們都要改變我們建站的方法了呢? 我們能不能繼續自動應用新的css屬性, 它們會變得可用嗎? 這是當我們還是討論"版本目標"的可行性時我的許多疑問中的幾個.
例如, 讓我們假設 ie 8不再繼續支持生成內容(generated content) - 如果acid2公布任何跡象的話, 它會, 請容忍我把它作為一個例子: 我們在"鎖定了" ie 8 的網站上使用生成內容的話, 另外除了ie之外的現代瀏覽器會渲染生成內容, 但是就算是ie 9又支持了生成內容, 有人用ie 9訪問這個網站的話, 還是會看不到生成內容, 因為這個網站被鎖定在 ie 8 了. 如果把這個網站的鎖定升級到ie 9, 那么生成內容就顯示出來了, 這是和逐步加強相違背的.
失去了逐步加強這個特點著實讓我頭痛, 但是這種行為是會發生的最好的事情了, 尤其是當網站是面向大眾的. 畢竟, 我們不應該去假設瀏覽器在將來會是什么樣. 如果 ie 9 的一個更改破壞了我們網站的布局或是我們的script中的一個功能的話, 這可能對于我們的用戶來說會災難性的, 并且會給我們的團隊帶來瘋狂的混亂 - 在新瀏覽器下修復這個網站的功能(我們已經上了太多條船了). 針對版本給我們團隊一種決定什么時候支持新瀏覽器的能力, 更重要的是, 給我們足夠的時間作出必要的調整來支持新瀏覽器.
針對版本意味著逐步加強的終結嗎? 在這個問題上, 不是. 首先, 我們仍然在未來的幾年內會處理遺留 / 預先鎖定瀏覽器, 并逐步加強, 這是個行之有效的方法將在他們中間逐步支持不同階段的css和javascript. 此外, 還有一個地方提供ie瀏覽器的樣式和腳本的補丁, 雖然我們希望隨著時間的過去這樣的需求會越來越少. 最后, 用逐步加強技術撰寫javascript仍舊會很大程度上減少為了準備支持新瀏覽器而作出的重構時間.
對于那些樂意拋棄嚴謹的態度的, 不計后果的, 或者其他不計后果的放任的口語化編程習慣, ie 會支持一個關鍵詞: "edge:"
<meta http-equiv="x-ua-compatible" content="ie=edge" />
這個選項, 雖然我們極力阻止, 但是這會讓一個網站把版本鎖定在所發布的最新的ie瀏覽器上. 這比設定一個不切實際的 ie=1000要來的清晰一點, 是吧? 但是從版本目標的所有優點來說, "edge"值除了實驗性的網站外都是不切實際的吧. 那是因為就算是 eric meyer也沒辦法預料在新版本瀏覽器中會有什么布局或是腳本的缺陷.
多年來, 我們設計師和開發者都渴望著有種方法可以讓我們的網站更可靠. 除了為撰寫跨平臺的樣式和腳本而頭痛, 我們還必須處理一些由于新瀏覽器的發布而造成的一些不可預料的損壞. 向客戶, 老板和用戶解釋這個不可預期的損壞從來不是個開心的差事. 但是, 通過ie 8的版本目標的介紹, 讓隧道的盡頭出現了一點光亮. 我, 作為其中一個, 希望其他的瀏覽器渲染都一起參加microsoft來貫徹這個方法.
個人并不是很贊同,這位標準推行者并沒有把目標放在如何讓標準的推行成為要務,卻又推出了ie 8中的version targeting功能,只能說,ie真的會慣壞一批開發者,不規范的編碼,和大量使用私有方法,難道又要浮上水面嗎?很難的推行了標準好些年,又準備回到那個混亂的年代了么...ie6 - ie7的轉變造成的大范圍災難說到底應該責怪誰呢? 不是m$自己我行我素的精神么?
ps. 這篇很像是m$的軟文...
過陣子再翻譯下eric meyer跳出來反對這種理論的文章, 理論性的爭論還是相當精彩的
新聞熱點
疑難解答
