Fresset Ltd （一个小型web广告公司）公司的联合创始人Lea Verou在本文中讨论了人们关于web标准的一些误解，以及W3C及其任务组真正在做些什么，以及标准化进程是如何任务的。

这是关于W3C任务组的系列文章的第一篇，次要关注CSS Working Group及相关任务。我觉得在我开始发表文章之前，有必要先清除一些关于web标准的广为流传的神话，并简单讲一下标准化进程是如何任务的。

一些术语

为了简单及精确起见，下面列出了一些术语，这些术语在本文中得以使用，在大多数与标准相关的讨论中也使用了这些术语：

Authors：开发人员，设计人员，或者说任何使用web技术的人。

Implementors：例如，那些提供开发者工具（developer tools）的公司。

Spec editors：撰写标准的人。与人们惯常的想法相反，他们并不是创造web技术的人。在下面你将更多读到关于这一点的内容。

1. ” W3C 创建了标准，然后浏览器必须去遵照”

浏览器创新与W3C创新（browser innovation vs W3C innovation）是一个广为流传的二元对立，然而这样的对立是错误的想法。简单来说，W3C实际上是implementors！Web标准是通过在Working Groups (WGs)中达成共识来实现的。这些WGs包括了各implementors的代表，次要是浏览器的代表。每个WG都有少量W3C成员，但他们只占少数。例如，在CSS WG中，如今有74名成员，其中只要4个（5.4%）是W3C成员（Bert Bos, Richard Ishida, Chris Lilley 以及 Liam Quin）。当然，浏览器通常本人先进行创新当前，然后随后再进行标准化（例如，rag & Drop API, CSS transitions, CSS transforms, CSS animations），但这样是很冒风险的，应该尽力避免。如果一个特写在标准化之前就广为流传了，那么，WG可能被迫去处理欠佳语法问题。

2. “你必须在大公司中任务，才能影响web标准”

如果你是在为一个成员公司任务，成为一个Working Group成员确实要容易得多。当然，除此以外，你还可以成为一个特邀专家（Invited Expert），但这对大多数WGs来说，都是分成困难的。CSS WG如今只要四个特邀专家（Molly Holzschlag, Koji Ishii, Brad Kemper 以及 Anton Prowse），在74名成员中只占5.4%。

然而，如果你想要有所奉献，并不非得是WG成员。每个WG都有一个地下邮件列表，每个好的想法都会被考虑，不论这个想法来自于谁。通常，不断在跟进某个列表的人可能会有更为无效的建议，由于他们对相关术语更为属性，并明白其中可能有的局限，但是这些对于提出一个值得考虑的想法来说，都不是必要的。

类似的，坏的想法都会被拒绝，即便这个想法来自于WG成员。这对于保持标准的高质量来说是非常重要的，由于任何人都可以加入WG。对于一个公司来说，要想成为W3C成员，所要做的只是有足够资金去交年费。任何一个来自于W3C成员公司的人都可以成员W3C成员，只需他们有时间，并且他们的雇主同意他们这样做。

3. “Spec editors创建web技术”

实际情形并非总是如此。W3C采取两种方式任务模式：

1. 先审查，再成文：首先，每一个细节都会在WG中进行讨论，然后editor必须将讨论结果写成正式文字 (正如某人所巧妙表达的那样，”忠实记录任务组的共识”).在这种任务模式下，editor和其他任何活跃参与这个讨论的人有相反权力。
2. 先成文，再审查：editor有更多权力去定义某种技术并在随后对标准的审查中也拥有更多权力。

CSS WG 次要是任务在第一种模式下，但并非每个WG都是如此。

4. “标准次要是为developers写的”

标准(specifications)实际上次要是为implementors写的，比如浏览器提供商（browser vendors）。有一些editors会将标准写得更为 author-friendly，但这并非是必须的。

5. “浏览器不能依托标准, 由于它们还在变化”

在实际操作中，一旦一个标准达到候选推荐（Candidate Recommendation ，CR）形状，几乎就不会再有什么严重改变了。晚期的一些形状（任务草案”Working Draft”和编辑草稿”Editor’s Draft”）是还在改变过程中的标准，因此，普通都会发生改变。在这些形状下的标准实现，通常是被看做实验性质的，甚至在CSS中，是需求加前缀的，以免与将来成形的更为稳定的对应标准发生冲突。在过去几年里，authors对实验性质依赖太多，将它们当做稳定标准。因此，这些实验性质的标准似乎就是标准，即便不可信，但实际并非如此。即便一个实验性的特性在web上广为使用，大多数WGs对于改变它们也颇为踌躇。这并不太好，由于这些特性往往并不完满，但是又不可避免要去使用，由于用其他方式的话将会使很多站点无法任务。

6. “CSS3和CSS4 是用以指代CSS版本的正式术语”

在CSS 2.1之后，CSS被分解成很多模块，每个模块都有本人的版本。建立在现有CSS 2.1特性之上的模块被称为是”Level 3″，但是新开发出的一些新的特性被认为是从”Level 1″开始的。不幸地是，很多新的起源于Level 3的模块，进一步促进了”CSS3″这个流行语的普及。然而，很多新模块（比如Variables），是起源于Level 1的。

从历史上来看，”CSS3″被用来描述在CSS2.1 之后出现的不管是什么级别的任何模块或者明确是Level 3的模块。这两种定义都有他们的问题。如果它是用来描述出现才CSS2.1之后的任何模块，那么如何区分CSS3 和 CSS4？如果它是用来描述明确属于Level 3的模块，那么它就毫无理由地排除了很多新的CSS模块。

7. “W3C 测试集是用来测试标准的分歧性的”

这是测试的一个很有用的功用，但是从推进W3C Recommendation的角度来说，测试只是为了确保标准中特性的可实现性，这意味着当浏览器无法正确实现某个特性时，可能并不是这个浏览器的错。缘由可能是这个标准写得不好，或者这个特性很难实现如它描述的那样，或者implementers对这个标准没有足够兴味。通常，当有至少两个浏览器通过测试当前，该标准就能继续推行。

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

完全