> 原文出處：http://www.w3cplus.com/css3/css-secrets/web-standards-friend-or-foe.html ## 標準化流程 與普通大眾的理解所不同的是，W3C（World Wide Web Consortium，萬維網聯盟）實際上并不制定標準。對于 W3C 旗下的各個工作組（Working Groups, WG）來說，W3C 更像是一個論壇，聚集各種興趣團體并讓他們為某個標準而努力。當然，W3C 并不只是作為整個論壇的觀察者：它制定整個論壇的基本規則并觀察標準制定的整個流程。在撰寫本書的時候，CSS WG 已經擁有了 98 個成員，其詳細組成如下： * **86**?名成員來自 W3C 的會員公司（88%） * **7**?名受邀專家（7%） * **5**?名 W3C 的全職員工（5%） 你可能已經注意到了，WG 的主要成員（88%）都來自 W3C 的會員公司。這些會員公司，包括了瀏覽器廠商、流行站點的維護商、研究機構和其他相關的常用技術公司，他們會因為 Web 標準化的流行而獲益匪淺。W3C 的會員年費支撐了 W3C 基金會的主要開銷，所以聯盟可以免費、開源的分發它的各類標準和規范——這與一些需要繳納授權費的標準化機構不同。 *受邀專家*是被邀請加入標準化制定流程的 Web 開發者，致力于解決規范制定初期調試時出現的連續性故障——他們往往具有非常深厚的技術背景。 最后，但非次要的是，W3C 還擁有一批為聯盟工作的全職員工，他們的主要工作就是協調、促進 WG 和 W3C 之間的聯絡。 在 Web 開發者中一直有個普遍性的錯誤觀念，認為 W3C 在上層制定了開發標準，然后各種瀏覽器無論是否愿意接受相關的標準，都必須去遵循和實踐。實際上，這種觀念跟現實相去甚遠：對于接受哪些方面的標準，瀏覽器廠商比 W3C 更有話語權 —— 上面列出的數字就說明了這個問題。 另一個與普通大眾的理解所不同的是：**標準不是憑空捏造的，制定標準也不是閉門造車**。CSS WG 所有的提交都是透明的，所有的交流都是對公眾開放的，歡迎審查和參與到相關項目鐘來： * 大部分的交流都記錄在它的郵件列表?[www-style](http://lists.w3.org/Archives/Public/www-style/)?中。www-style 是公開存檔的，任何人都可以參與到其中。 * 然后，還有一個時長為一小時的?**每周電話會議（weekly telcon）**。它并不對 WG 成員之外的公眾開放，但相關內容會被記錄在?**[the W3C's IRC server](http://irc.w3.org/)**?的?**#css**?板塊中。幾天后，這些記錄會被清除，然后發布到郵件劉表中。 * 最后，還有一個**季度性的面對面會議（quarterly face-to-face meetings）**，會議內容也會像電話會議一樣被記錄。如果獲得 WG 主席們的同意，那么也可以旁聽該會議。 上述所有的內容都只是 W3C 流程中與決策相關的一部分。不過，具體負責編寫標準或規范的人，是規范編輯（*Spec Editos*）。規范編輯可能是來自 W3C 的全職員工、瀏覽器開發者、受邀專家，也可能是來自 W3C 會員公司的全職員工——這些員工由相關公司支付薪水，用以加快推動標準的制定和實施，從而獲得公共利益。 每一份規范從誕生到成熟都要經歷多個階段： * **編輯草案（Editor's Draft, ED）:**在規范的第一個階段，它的內容會比較混亂，只是規范編輯（Spac Editor）整理收集來的各種想法。對于處于這一階段的規范，不附加任何必要條件，也不保證會被 WG 批準。此外，這也是修改版的第一個階段：所有的修改內容首先要經過 ED，然后才能被發布。 * **第一次公開工作草案（First Public Working Draft, FPWD）:**在這一階段將會發布規范的第一個公開版本，此時往往認為規范可以接受來自 WG 的公開反饋了。 * **工作草案（Working Draft, WD）:**在第一次公開工作草案發布之后還會有數個工作草案（WDs），新的工作草案會整合來自 WG 和其他更寬泛社區的反饋，進行增量優化。在這一階段往往會出現第一個實現，但該實現并不是沒有經歷實驗測試的低級版本。 * **候選推薦標準（Candidate Recommendation, CR）:**該階段的規范會被看做是相對穩定的版本，接著就會對它進行實現和測試。任何一個規范都不能在沒有完整測試的情況下通過該階段，而且至少要有兩個獨立的實現。 * **建議推薦標準（Proposed Recommendation, PR）:**該階段是 W3C 會員公司對規范發表異議的最后時機。這種異議很少發生，所以推動該階段的規范進入最終階段就只是時間的問題了。 * **推薦標準（Recommendation, REC）:**?W3C 規范的最后一個階段。 WG 成員中的一到兩位會成為 WG 主席。主席負責組織會議、協調電話、把握進度，基本上是總攬全局。擔任主席一角是非常消耗時間和精力的事情，他們常常被形容為**在放牧一群貓**。當然，參與制定標準的每一個人都知道這種比較是沒有實際意義的：畢竟放牧一群貓事實上要容易的多。 > 想要了解更多信息？Elika Etemad 編寫了[一系列精彩的文章，詳細介紹了 CSS WG 的運作方式](http://fantasai.inkedblade.net/weblog/2011/inside-csswg/)。強烈建議閱讀一下。 ## CSS3，CSS4 和其他的神奇特征 由 Ha?kon Wium Lie 和 Bert Bos 發布于 1996 年的 CSS 1 是一份非常簡略的規范。它內容短小，以至于可以直接放在一個簡單的 HTML 頁面中，只需大約 64 張 A4 紙就可以打印出所有的內容。 發布于 1998 年的 CSS 2，其內容定義地更加嚴格，也包含了更多強大的特性，而且還吸納了兩個重要的規范編輯： Chris Lilley 和 Ian Jacobs。此時，它的內容量已經增長到了需要 480 頁打印紙才能完全打印出來，幾乎不可能被人類完全記憶。 在 CSS 2 之后，CSS WG 認識到了 CSS 的內容量太大，以至于不能將其歸納到一個簡單的規范中。這不只讓規范變得難以閱讀和編輯，也阻礙了 CSS 的進一步發展。任何一個規范想要成為推薦標準，那么它的每一個標準至少需要擁有兩個獨立的實現并通過嚴格的測試。顯然，這是不切實際的。因此，為了推動 CSS 的發展，CSS 被分隔成了多個模塊，每個模塊都有自己獨立的版本。那些計劃出現在 CSS2.1 中的特性因此擁有了一個 Level 3 的編號，比如下面的這些模塊： * [CSS Syntax](http://www.w3.org/TR/css-syntax-3/) * [CSS Cascading and Inheritance](http://w3.org/TR/css-cascade-3) * [CSS Color](http://www.w3.org/TR/css3-color/) * [Selectors](http://www.w3.org/TR/selectors/) * [CSS Backgrounds & Borders](http://www.w3.org/TR/css3-background/) * [CSS Values and Units](http://www.w3.org/TR/css-values-3/) * [CSS Text](http://www.w3.org/TR/css-text-3/) * [CSS Text Decoration](http://www.w3.org/TR/css-text-decor-3/) * [CSS Fonts](http://www.w3.org/TR/css3-fonts/) * [CSS Basic User Interface](http://www.w3.org/TR/css3-ui/) 不過，模塊化這一新概念是從 Level 1 開始的，比如下面的這些示例： * [CSS Transforms](http://www.w3.org/TR/css-transforms-1/) * [Compositing and Blending](http://www.w3.org/TR/compositing-1/) * [Filter Effects](http://www.w3.org/TR/filter-effects-1/) * [CSS Masking](http://www.w3.org/TR/css-masking-1/) * [CSS Flexible Box Layout](http://www.w3.org/TR/css-flexbox-1/) * [CSS Grid Layout](http://www.w3.org/TR/css-grid-1/) **雖然 “CSS3” 這個詞很流行，但實際上并沒有類似 CSS 2.1 以及之前版本那樣完整的規范。**相反，大多數作者只是粗略地引用了一些 Level 3 和 Level 1 的規范。雖然對于 “CSS3” 在作者中有一個共識性的規范范圍，但因為過去幾年 CSS 模塊發展地非常不均衡，所有越來越難用類似 CSS3、CSS4 等術語來定義一個一致性的術語了。 ## 瀏覽器前綴的冰火兩重天 在標準的開發過程中，一直有一個“第二十二條軍規”（源自美國作家約瑟夫·海勒的著作《第22條軍規》，引申為荒唐的事情）：標準制定小組需要根據開發者的需求創建規范。然而，開發者通常沒興趣去測試那些不會應用到產品中的特性。當實驗性特性被廣泛用于線上產品中時，WG 被迫跟進相關的技術，避免對現有網站的破壞。顯而易見，開發者不提前測試相關標準，導致了后期開發受制于歷史因素。 過去幾年，業界提出了許多種方案來解決這個問題，但都不夠完美。普遍受人厭惡的瀏覽器前綴就是其中一種方案。該方案的具體做法是，對于瀏覽器中的實驗性特性（甚至是專有特性），提供一種附加瀏覽器前綴名的命名方案。最常見的前綴就是 Firefox 的?`-moz`，IE 的?`-ms-`，Opera 的?`-o-`?以及 Safari 和 Chrome 的?`-webkit-`。開發者可以毫無限制地使用前綴命名方式調用測試新特性，然后將使用信息反饋給 WG——WG 獲得反饋之后可以進一步測試，直至完善。因此，即使在最終的標準化規范中相關特性擁有了不同的名字（沒有前綴），也不會與現有的屬性（有前綴）相沖突。 聽起來還不錯，是吧？如你所知，現實與理想總是有差距的。使用具有瀏覽器前綴的實驗性特性讓開發者認識到，創建頁面特效原來可以這么簡單，以至于他們開始在任何地方使用這些特性。使用具有瀏覽器前綴的屬性成為了 CSS 的一種流行趨勢：CSS 的教程里用這些屬性、StackOverflow 的回答里用這些屬性……很快，每一個獨立的 CSS 開發者也開始毫無顧忌地使用它們。 最終，開發者們認識到了，只添加既有的瀏覽器前綴將會讓他們不停地維護過去的項目：當其他瀏覽器實現了他們偏愛的酷炫特性時，他們必須手動地再去添加一次。不用多說相信你也會理解，不停地跟進這些新特性是一件非常痛苦的事情。那有沒有什么解決方案呢？提前添加好所有可能的瀏覽器前綴，包括那些尚未實現該屬性的瀏覽器前綴，從而達到防患于未然的目的。最終，我們可能就會像下面這樣編碼： ~~~ -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 從一開始就實現了無前綴版本的?`border-radius`?屬性。 顯然，將每種屬性重復聲明五次是單調乏味和不可維護的。看來使用工具實現自動添加只是一個時間問題了： * 類似?**[CSS3 Please!](http://css3please.com/)**?和?**[pleeease](http://pleeease.io/playground.html)**?的網站，可以在你粘帖未加瀏覽器前綴的屬性后，返回給你一個添加了所有可用瀏覽器前綴的屬性。此類應用是最早一批嘗試自動補全瀏覽器前綴的先驅，但是隨著其他方案的崛起，該方案顯得越來越笨拙，已經不再那么流行了。 * [Autoprefixer](https://github.com/postcss/autoprefixer)?通過使用?[Can I Use...](http://caniuse.com/)?的數據庫，更智能地判斷屬性應該添加哪些瀏覽器前綴，并且能像預處理器一樣在本地進行編譯和執行。 * 我個人開發的?[-prefix-free](http://leaverou.github.io/prefixfree/)?可以直接在瀏覽器本地進行特征檢測，從而判斷所需的瀏覽器前綴。這樣做的好處是很少需要更新該工具，它從瀏覽器本地環境獲取所需的數據，包括必須的屬性列表。 * 類似?[LESS](http://lesscss.org/)?和?[Sass](http://sass-lang.com/)?的預處理器雖然沒有提供任何直接的瀏覽器前綴工具，但是有很多開發者為常用的屬性創建了混合宏，目前也有幾個流行的混合宏庫。 由于開發者使用無前綴屬性保證代碼在未來的可用性，所以基本不可能改變這種編程習慣。基本上，我們只能使用早期不完善的規范來做開發，實際使用過程中可以改變的地方極其有限。不用多長時間，每個人都會認識到瀏覽器前綴就是個悲劇。 近些日子，新的實驗性屬性已經很少使用瀏覽器前綴了。相反的是，要想使用實驗性屬性就需要在瀏覽器設置中開啟相關選項，因為開發者不能告訴用戶開啟相關選項來瀏覽頁面，所以這種方法可以有效防止開發者將這些屬性應用到線上環境中。當然，這樣做的后果就是很少有開發者會把玩這些實驗性屬性。但是，我們還是能夠獲得足夠的反饋——可以肯定的說，相比較使用瀏覽器前綴的方案，這種反饋的質量更高。不過，瀏覽器前綴的困擾還會存在很長時間。