破除八大Web标准迷思：只有大公司才能影响标准

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”

完全不是这样。当W3C在1994年创建的时候，CSS根本就不存在。除了CSS，很多其他重要的web技术都是由W3C创建的，要么是由它独立创建，要么是和其他标准组织进行了合作：