Web 標準是友是敵？

原文出處：http://www.w3cplus.com/css3/css-secrets/web-standards-friend-or-foe.html

標準化流程

與普通大眾的理解所不同的是，W3C（World Wide Web Consortium，萬維網(wǎng)聯(lián)盟）實際上并不制定標準。對于 W3C 旗下的各個工作組（Working Groups, WG）來說，W3C 更像是一個論壇，聚集各種興趣團體并讓他們?yōu)槟硞€標準而努力。當然，W3C 并不只是作為整個論壇的觀察者：它制定整個論壇的基本規(guī)則并觀察標準制定的整個流程。在撰寫本書的時候，CSS WG 已經(jīng)擁有了 98 個成員，其詳細組成如下：

• 86?名成員來自 W3C 的會員公司（88%）
• 7?名受邀專家（7%）
• 5?名 W3C 的全職員工（5%）

你可能已經(jīng)注意到了，WG 的主要成員（88%）都來自 W3C 的會員公司。這些會員公司，包括了瀏覽器廠商、流行站點的維護商、研究機構(gòu)和其他相關(guān)的常用技術(shù)公司，他們會因為 Web 標準化的流行而獲益匪淺。W3C 的會員年費支撐了 W3C 基金會的主要開銷，所以聯(lián)盟可以免費、開源的分發(fā)它的各類標準和規(guī)范——這與一些需要繳納授權(quán)費的標準化機構(gòu)不同。

受邀專家是被邀請加入標準化制定流程的 Web 開發(fā)者，致力于解決規(guī)范制定初期調(diào)試時出現(xiàn)的連續(xù)性故障——他們往往具有非常深厚的技術(shù)背景。

最后，但非次要的是，W3C 還擁有一批為聯(lián)盟工作的全職員工，他們的主要工作就是協(xié)調(diào)、促進 WG 和 W3C 之間的聯(lián)絡(luò)。

在 Web 開發(fā)者中一直有個普遍性的錯誤觀念，認為 W3C 在上層制定了開發(fā)標準，然后各種瀏覽器無論是否愿意接受相關(guān)的標準，都必須去遵循和實踐。實際上，這種觀念跟現(xiàn)實相去甚遠：對于接受哪些方面的標準，瀏覽器廠商比 W3C 更有話語權(quán) —— 上面列出的數(shù)字就說明了這個問題。

另一個與普通大眾的理解所不同的是：標準不是憑空捏造的，制定標準也不是閉門造車。CSS WG 所有的提交都是透明的，所有的交流都是對公眾開放的，歡迎審查和參與到相關(guān)項目鐘來：

• 大部分的交流都記錄在它的郵件列表?www-style?中。www-style 是公開存檔的，任何人都可以參與到其中。
• 然后，還有一個時長為一小時的?每周電話會議（weekly telcon）。它并不對 WG 成員之外的公眾開放，但相關(guān)內(nèi)容會被記錄在?the W3C's IRC server?的?#css?板塊中。幾天后，這些記錄會被清除，然后發(fā)布到郵件劉表中。
• 最后，還有一個季度性的面對面會議（quarterly face-to-face meetings），會議內(nèi)容也會像電話會議一樣被記錄。如果獲得 WG 主席們的同意，那么也可以旁聽該會議。

上述所有的內(nèi)容都只是 W3C 流程中與決策相關(guān)的一部分。不過，具體負責編寫標準或規(guī)范的人，是規(guī)范編輯（Spec Editos）。規(guī)范編輯可能是來自 W3C 的全職員工、瀏覽器開發(fā)者、受邀專家，也可能是來自 W3C 會員公司的全職員工——這些員工由相關(guān)公司支付薪水，用以加快推動標準的制定和實施，從而獲得公共利益。

每一份規(guī)范從誕生到成熟都要經(jīng)歷多個階段：

• 編輯草案（Editor's Draft, ED）:在規(guī)范的第一個階段，它的內(nèi)容會比較混亂，只是規(guī)范編輯（Spac Editor）整理收集來的各種想法。對于處于這一階段的規(guī)范，不附加任何必要條件，也不保證會被 WG 批準。此外，這也是修改版的第一個階段：所有的修改內(nèi)容首先要經(jīng)過 ED，然后才能被發(fā)布。
• 第一次公開工作草案（First Public Working Draft, FPWD）:在這一階段將會發(fā)布規(guī)范的第一個公開版本，此時往往認為規(guī)范可以接受來自 WG 的公開反饋了。
• 工作草案（Working Draft, WD）:在第一次公開工作草案發(fā)布之后還會有數(shù)個工作草案（WDs），新的工作草案會整合來自 WG 和其他更寬泛社區(qū)的反饋，進行增量優(yōu)化。在這一階段往往會出現(xiàn)第一個實現(xiàn)，但該實現(xiàn)并不是沒有經(jīng)歷實驗測試的低級版本。
• 候選推薦標準（Candidate Recommendation, CR）:該階段的規(guī)范會被看做是相對穩(wěn)定的版本，接著就會對它進行實現(xiàn)和測試。任何一個規(guī)范都不能在沒有完整測試的情況下通過該階段，而且至少要有兩個獨立的實現(xiàn)。
• 建議推薦標準（Proposed Recommendation, PR）:該階段是 W3C 會員公司對規(guī)范發(fā)表異議的最后時機。這種異議很少發(fā)生，所以推動該階段的規(guī)范進入最終階段就只是時間的問題了。
• 推薦標準（Recommendation, REC）:?W3C 規(guī)范的最后一個階段。

WG 成員中的一到兩位會成為 WG 主席。主席負責組織會議、協(xié)調(diào)電話、把握進度，基本上是總攬全局。擔任主席一角是非常消耗時間和精力的事情，他們常常被形容為在放牧一群貓。當然，參與制定標準的每一個人都知道這種比較是沒有實際意義的：畢竟放牧一群貓事實上要容易的多。

想要了解更多信息？Elika Etemad 編寫了一系列精彩的文章，詳細介紹了 CSS WG 的運作方式。強烈建議閱讀一下。

CSS3，CSS4 和其他的神奇特征

由 Ha?kon Wium Lie 和 Bert Bos 發(fā)布于 1996 年的 CSS 1 是一份非常簡略的規(guī)范。它內(nèi)容短小，以至于可以直接放在一個簡單的 HTML 頁面中，只需大約 64 張 A4 紙就可以打印出所有的內(nèi)容。

發(fā)布于 1998 年的 CSS 2，其內(nèi)容定義地更加嚴格，也包含了更多強大的特性，而且還吸納了兩個重要的規(guī)范編輯： Chris Lilley 和 Ian Jacobs。此時，它的內(nèi)容量已經(jīng)增長到了需要 480 頁打印紙才能完全打印出來，幾乎不可能被人類完全記憶。

在 CSS 2 之后，CSS WG 認識到了 CSS 的內(nèi)容量太大，以至于不能將其歸納到一個簡單的規(guī)范中。這不只讓規(guī)范變得難以閱讀和編輯，也阻礙了 CSS 的進一步發(fā)展。任何一個規(guī)范想要成為推薦標準，那么它的每一個標準至少需要擁有兩個獨立的實現(xiàn)并通過嚴格的測試。顯然，這是不切實際的。因此，為了推動 CSS 的發(fā)展，CSS 被分隔成了多個模塊，每個模塊都有自己獨立的版本。那些計劃出現(xiàn)在 CSS2.1 中的特性因此擁有了一個 Level 3 的編號，比如下面的這些模塊：

• CSS Syntax
• CSS Cascading and Inheritance
• CSS Color
• Selectors
• CSS Backgrounds & Borders
• CSS Values and Units
• CSS Text
• CSS Text Decoration
• CSS Fonts
• CSS Basic User Interface

不過，模塊化這一新概念是從 Level 1 開始的，比如下面的這些示例：

• CSS Transforms
• Compositing and Blending
• Filter Effects
• CSS Masking
• CSS Flexible Box Layout
• CSS Grid Layout

雖然 “CSS3” 這個詞很流行，但實際上并沒有類似 CSS 2.1 以及之前版本那樣完整的規(guī)范。相反，大多數(shù)作者只是粗略地引用了一些 Level 3 和 Level 1 的規(guī)范。雖然對于 “CSS3” 在作者中有一個共識性的規(guī)范范圍，但因為過去幾年 CSS 模塊發(fā)展地非常不均衡，所有越來越難用類似 CSS3、CSS4 等術(shù)語來定義一個一致性的術(shù)語了。

瀏覽器前綴的冰火兩重天

在標準的開發(fā)過程中，一直有一個“第二十二條軍規(guī)”（源自美國作家約瑟夫·海勒的著作《第22條軍規(guī)》，引申為荒唐的事情）：標準制定小組需要根據(jù)開發(fā)者的需求創(chuàng)建規(guī)范。然而，開發(fā)者通常沒興趣去測試那些不會應(yīng)用到產(chǎn)品中的特性。當實驗性特性被廣泛用于線上產(chǎn)品中時，WG 被迫跟進相關(guān)的技術(shù)，避免對現(xiàn)有網(wǎng)站的破壞。顯而易見，開發(fā)者不提前測試相關(guān)標準，導(dǎo)致了后期開發(fā)受制于歷史因素。

過去幾年，業(yè)界提出了許多種方案來解決這個問題，但都不夠完美。普遍受人厭惡的瀏覽器前綴就是其中一種方案。該方案的具體做法是，對于瀏覽器中的實驗性特性（甚至是專有特性），提供一種附加瀏覽器前綴名的命名方案。最常見的前綴就是 Firefox 的?-moz，IE 的?-ms-，Opera 的?-o-?以及 Safari 和 Chrome 的?-webkit-。開發(fā)者可以毫無限制地使用前綴命名方式調(diào)用測試新特性，然后將使用信息反饋給 WG——WG 獲得反饋之后可以進一步測試，直至完善。因此，即使在最終的標準化規(guī)范中相關(guān)特性擁有了不同的名字（沒有前綴），也不會與現(xiàn)有的屬性（有前綴）相沖突。

聽起來還不錯，是吧？如你所知，現(xiàn)實與理想總是有差距的。使用具有瀏覽器前綴的實驗性特性讓開發(fā)者認識到，創(chuàng)建頁面特效原來可以這么簡單，以至于他們開始在任何地方使用這些特性。使用具有瀏覽器前綴的屬性成為了 CSS 的一種流行趨勢：CSS 的教程里用這些屬性、StackOverflow 的回答里用這些屬性……很快，每一個獨立的 CSS 開發(fā)者也開始毫無顧忌地使用它們。

最終，開發(fā)者們認識到了，只添加既有的瀏覽器前綴將會讓他們不停地維護過去的項目：當其他瀏覽器實現(xiàn)了他們偏愛的酷炫特性時，他們必須手動地再去添加一次。不用多說相信你也會理解，不停地跟進這些新特性是一件非常痛苦的事情。那有沒有什么解決方案呢？提前添加好所有可能的瀏覽器前綴，包括那些尚未實現(xiàn)該屬性的瀏覽器前綴，從而達到防患于未然的目的。最終，我們可能就會像下面這樣編碼：

-moz-border-radius: 10px;
-ms-border-radius: 10px;
-o-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;

上面的代碼中有兩處完全是多余的：-ms-border-radius?和?-o-border-radius?永遠不會生效，因為 IE 和 Opera 從一開始就實現(xiàn)了無前綴版本的?border-radius?屬性。

顯然，將每種屬性重復(fù)聲明五次是單調(diào)乏味和不可維護的?？磥硎褂霉ぞ邔崿F(xiàn)自動添加只是一個時間問題了：

• 類似?CSS3 Please!?和?pleeease?的網(wǎng)站，可以在你粘帖未加瀏覽器前綴的屬性后，返回給你一個添加了所有可用瀏覽器前綴的屬性。此類應(yīng)用是最早一批嘗試自動補全瀏覽器前綴的先驅(qū)，但是隨著其他方案的崛起，該方案顯得越來越笨拙，已經(jīng)不再那么流行了。
• Autoprefixer?通過使用?Can I Use...?的數(shù)據(jù)庫，更智能地判斷屬性應(yīng)該添加哪些瀏覽器前綴，并且能像預(yù)處理器一樣在本地進行編譯和執(zhí)行。
• 我個人開發(fā)的?-prefix-free?可以直接在瀏覽器本地進行特征檢測，從而判斷所需的瀏覽器前綴。這樣做的好處是很少需要更新該工具，它從瀏覽器本地環(huán)境獲取所需的數(shù)據(jù)，包括必須的屬性列表。
• 類似?LESS?和?Sass?的預(yù)處理器雖然沒有提供任何直接的瀏覽器前綴工具，但是有很多開發(fā)者為常用的屬性創(chuàng)建了混合宏，目前也有幾個流行的混合宏庫。

由于開發(fā)者使用無前綴屬性保證代碼在未來的可用性，所以基本不可能改變這種編程習(xí)慣?；旧?，我們只能使用早期不完善的規(guī)范來做開發(fā)，實際使用過程中可以改變的地方極其有限。不用多長時間，每個人都會認識到瀏覽器前綴就是個悲劇。

近些日子，新的實驗性屬性已經(jīng)很少使用瀏覽器前綴了。相反的是，要想使用實驗性屬性就需要在瀏覽器設(shè)置中開啟相關(guān)選項，因為開發(fā)者不能告訴用戶開啟相關(guān)選項來瀏覽頁面，所以這種方法可以有效防止開發(fā)者將這些屬性應(yīng)用到線上環(huán)境中。當然，這樣做的后果就是很少有開發(fā)者會把玩這些實驗性屬性。但是，我們還是能夠獲得足夠的反饋——可以肯定的說，相比較使用瀏覽器前綴的方案，這種反饋的質(zhì)量更高。不過，瀏覽器前綴的困擾還會存在很長時間。