這是關(guān)于W3C工作組的系列文章的第一篇，主要關(guān)注CSS Working Group及相關(guān)工作。我覺得在我開始發(fā)表文章之前，有必要先清除一些關(guān)于web標準的廣為流傳的神話，并簡單講一下標準化進程是如何工作的。

一些術(shù)語

為了簡單及精確起見，下面列出了一些術(shù)語，這些術(shù)語在本文中得以使用，在大多數(shù)與標準相關(guān)的討論中也使用了這些術(shù)語：

Authors：開發(fā)人員，設計人員，或者說任何使用web技術(shù)的人。

Implementors：例如，那些提供開發(fā)者工具（developer tools）的公司。

Spec editors：撰寫標準的人。與人們慣常的想法相反，他們并不是創(chuàng)造web技術(shù)的人。在下面你將更多讀到關(guān)于這一點的內(nèi)容。

1. ” W3C 創(chuàng)建了標準，然后瀏覽器必須去遵循”

瀏覽器創(chuàng)新與W3C創(chuàng)新（browser innovation vs W3C innovation）是一個廣為流傳的二元對立，然而這樣的對立是錯誤的想法。簡單來說，W3C實際上是implementors！Web標準是通過在Working Groups (WGs)中達成共識來實現(xiàn)的。這些WGs包括了各implementors的代表，主要是瀏覽器的代表。每個WG都有少量W3C成員，但他們只占少數(shù)。例如，在CSS WG中，現(xiàn)在有74名成員，其中只有4個（5.4%）是W3C成員（Bert Bos, Richard Ishida, Chris Lilley 以及 Liam Quin）。當然，瀏覽器通常自己先進行創(chuàng)新以后，然后隨后再進行標準化（例如，rag & Drop API, CSS transitions, CSS transforms, CSS animations），但這樣是很冒風險的，應該盡力避免。如果一個特寫在標準化之前就廣為流傳了，那么，WG可能被迫去解決欠佳語法問題。

2. “你必須在大公司中工作，才能影響web標準”

如果你是在為一個成員公司工作，成為一個Working Group成員確實要容易得多。當然，除此以外，你還可以成為一個特邀專家（Invited Expert），但這對大多數(shù)WGs來說，都是分成困難的。CSS WG現(xiàn)在只有四個特邀專家（Molly Holzschlag, Koji Ishii, Brad Kemper 以及 Anton Prowse），在74名成員中只占5.4%。

然而，如果你想要有所貢獻，并不非得是WG成員。每個WG都有一個公開郵件列表，每個好的想法都會被考慮，不論這個想法來自于誰。通常，一直在跟進某個列表的人可能會有更為有效的建議，因為他們對相關(guān)術(shù)語更為屬性，并明白其中可能有的局限，但是這些對于提出一個值得考慮的想法來說，都不是必要的。

類似的，壞的想法都會被拒絕，即使這個想法來自于WG成員。這對于保持標準的高質(zhì)量來說是非常重要的，因為任何人都可以加入WG。對于一個公司來說，要想成為W3C成員，所要做的只是有足夠資金去交年費。任何一個來自于W3C成員公司的人都可以成員W3C成員，只要他們有時間，并且他們的雇主同意他們這樣做。

3. “Spec editors創(chuàng)建web技術(shù)”

實際情形并非總是如此。W3C采取兩種方式工作模式：

先審查，再成文：首先，每一個細節(jié)都會在WG中進行討論，然后editor必須將討論結(jié)果寫成正式文字 (正如某人所巧妙表達的那樣，”忠實記錄工作組的共識”).在這種工作模式下，editor和其他任何活躍參與這個討論的人有相同權(quán)力。 先成文，再審查：editor有更多權(quán)力去定義某種技術(shù)并在隨后對標準的審查中也擁有更多權(quán)力。

CSS WG 主要是工作在第一種模式下，但并非每個WG都是如此。

4. “標準主要是為developers寫的”

標準(specifications)實際上主要是為implementors寫的，比如瀏覽器提供商（browser vendors）。有一些editors會將標準寫得更為 author-friendly，但這并非是必須的。

5. “瀏覽器不能依靠標準, 因為它們還在變化”

在實際操作中，一旦一個標準達到候選推薦（Candidate Recommendation ，CR）狀態(tài)，幾乎就不會再有什么重大改變了。早期的一些狀態(tài)（工作草案”Working Draft”和編輯草稿”Editor’s Draft”）是還在改變過程中的標準，因此，一般都會發(fā)生改變。在這些狀態(tài)下的標準實現(xiàn)，通常是被看做實驗性質(zhì)的，甚至在CSS中，是需要加前綴的，以免與將來成形的更為穩(wěn)定的對應標準發(fā)生沖突。在過去幾年里，authors對實驗性質(zhì)依賴太多，將它們當做穩(wěn)定標準。因此，這些實驗性質(zhì)的標準似乎就是標準，即使不可信，但實際并非如此。即使一個實驗性的特性在web上廣為使用，大多數(shù)WGs對于改變它們也頗為躊躇。這并不太好，因為這些特性往往并不完美，但是又不可避免要去使用，因為用其他方式的話將會使很多站點無法工作。

6. “CSS3和CSS4 是用以指代CSS版本的正式術(shù)語”

在CSS 2.1之后，CSS被分解成很多模塊，每個模塊都有自己的版本。建立在現(xiàn)有CSS 2.1特性之上的模塊被稱為是”Level 3″，但是新開發(fā)出的一些新的特性被認為是從”Level 1″開始的。不幸地是，很多新的起源于Level 3的模塊，進一步促進了”CSS3″這個流行語的普及。然而，很多新模塊（比如Variables），是起源于Level 1的。

從歷史上來看，”CSS3″被用來描述在CSS2.1 之后出現(xiàn)的不管是什么級別的任何模塊或者明確是Level 3的模塊。這兩種定義都有他們的問題。如果它是用來描述出現(xiàn)才CSS2.1之后的任何模塊，那么如何區(qū)分CSS3 和 CSS4？如果它是用來描述明確屬于Level 3的模塊，那么它就毫無理由地排除了很多新的CSS模塊。

7. “W3C 測試集是用來測試標準的一致性的”

這是測試的一個很有用的功能，但是從推進W3C Recommendation的角度來說，測試只是為了確保標準中特性的可實現(xiàn)性，這意味著當瀏覽器無法正確實現(xiàn)某個特性時，可能并不是這個瀏覽器的錯。原因可能是這個標準寫得不好，或者這個特性很難實現(xiàn)如它描述的那樣，或者implementers對這個標準沒有足夠興趣。通常，當有至少兩個瀏覽器通過測試以后，該標準就能繼續(xù)推行。

8. “W3C = CSS WG + 一些小的重要的WGs”

完全不是這樣。當W3C在1994年創(chuàng)建的時候，CSS根本就不存在。除了CSS，很多其他重要的web技術(shù)都是由W3C創(chuàng)建的，要么是由它獨立創(chuàng)建，要么是和其他標準組織進行了合作：

HTML DOM API Selectors API XMLHttpRequest XML SVG MathML The PNG file format SOAP

還包括很多其他重要的web技術(shù)。進一步說， CSS WG甚至不是大的 WG。例如，WebApps WG有146個成員.

文章標題：WEB標準化進程
地址分享：http://jinyejixie.com/news16/326016.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設計、虛擬主機、小程序開發(fā)、電子商務、面包屑導航、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)