[译] [101] Web 标准：是敌是友？ #7
Labels
Comments
|
猫咪好萌，色彩真漂亮 |
|
一群专家们各有各的意见，协调各方可以想象是多难的事情…… |
|
到底，CSS 有多少种布局方式？感觉很多中文名上都混淆了…… |
Open
|
开始看啦~~~ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Web standards: friend or foe?
Web 标准：是敌是友？
The standards process
标准的制定过程
Contrary to popular belief, the W3C does not “make” standards. Instead, it acts as a forum for interested parties to get together and do so, in its W3C Working Groups. Of course, the W3C is not a mere observer: it sets the ground rules and it oversees the process. But it’s not (primarily) W3C staff that actually write the specifications.
与大众的理解大相径庭的是，W3C 并不 “生产” 标准。实际上，它扮演的是一个论坛的角色——W3C 以工作组的方式，把某项技术的相关各方聚集起来，最终由他们来产出标准。当然，W3C 并不只是一个观察者：它设定了整个平台的规则，监督整个进程。但这些技术规范（基本上）并不是由 W3C 的工作人员编写完成的。
CSS specifications, in particular, are written by the members of the CSS Working Group, often abbreviated as CSS WG. At the time of writing, the CSS WG includes 98 members, and its composition is as follows:
CSS 规范通常是由 CSS 工作组的成员来编写的。在编写本书时，CSS 工作组共有 98 名成员，人员结构如下：
As you might notice, the vast majority of WG members (88%) come from W3C member companies. These are companies--such as browser vendors, popular websites, research institutes, general technology companies, etc.--that have a vested interest in seeing web standards flourish. Their yearly membership dues represent the majority of the W3C’s funding, enabling the Consortium to distribute its specifications freely and openly, unlike other standards bodies that have to charge for them.
你可能注意到了，工作组的绝大多数成员（88%）来自于 W3C 会员公司。这些公司（比如浏览器厂商、主流网站、研究机构、常规技术公司等）都是 Web 标准兴旺发展的直接受益者。它们每年的会费也是 W3C 的主要资金来源，使得 W3C 能够免费、开放地发布所有技术规范，而不像其他标准制定组织那样不得不采取收费政策来维持运作。
Invited Experts are web developers who have been asked to participate in the standards process, after demonstrating a continuous commitment to helping out, and a sufficient technical background to participate in the discussions.
特邀专家是指那些被邀请参与标准制定的 Web 开发者。在真正获得这样的殊荣之前，他们需要证明自己在解决难题时能够持续不断地投入、在参与讨论时能够体现出深厚的技术背景。
Last, but not least, W3C staff members are people who actually work at the Consortium and facilitate communication between the WG and the W3C.
最后，同样不可忽视的是W3C 工作人员。他们才是真正在 W3C 内工作的人，他们为工作组和 W3C 之间的交流提供便利。
A widespread misconception among web developers is that the W3C creates standards from up high that the poor browsers then have to follow, whether they like them or not. However, this couldn’t be further from the truth: browser vendors have much more of a say than the W3C in what goes into standards, as evidenced by the numbers listed before.
Web 开发者们普遍存在一个误解，以为 W3C 手握标准、号令天下，而可怜的浏览器厂商们则唯唯诺诺、莫敢不从。但这显然不是真相——对于哪些东西该进入标准，浏览器厂商们比 W3C 有多得多的发言权，因为上面列出的人员结构已经证明了这一点。
Also contrary to popular belief, standards are not created in a vacuum, behind closed doors. The CSS WG is committed to transparency and all its communications are open to the public, inviting review and participation:
同样跟大众观念截然相反的是，标准并不是闭门造车造出来的。CSS 工作组坚持透明原则，它内部所有的交流都是公开的，并邀请公众的关注和参与：
All this is part of the W3C process and has to do with decision making. However, the ones that are actually responsible for putting these decisions to writing (i.e., authoring the specifications) are the Spec Editors. Spec Editors might be W3C staff members, browser developers, interested Invited Experts, or member company employees who are doing it as a full-time job, paid by their companies to advance standards for the common good.
所有这些都是 W3C 进程的一部分，任何决定都是通过这样的方式来产生的。此外，那些真正负责把这些决定写成文字（即编撰规范）的人叫作规范编辑。规范编辑可能是 W3C 的工作人员、浏览器开发者、相关专业的特邀专家，也可能是会员公司的雇员，他们全职受薪从事此工作、为了共同利益去推进标准。
Each specification goes through multiple stages as it evolves from initial inception to maturity:
每项规范从最初启动到最终成熟，都会经过以下这些阶段：
One or two WG members have the role of being chairs. Chairs are responsible for organizing meetings, coordinating calls, timekeeping, and generally moderating the whole thing. Being chair is a very time-consuming and energy-draining role, and is frequently compared to herding cats. Of course, everyone involved in standards knows that such a comparison is moot: herding cats is actually considerably easier.
工作组中会有一到两位成员将会担任主席的角色。主席负责组织会议、协调讨论、控制时间，而且要从大局上去斡旋整件事情。担任主席是一件耗时费神的工作，经常被比作放养一大群猫。当然，所有接触过这项工作的人都知道这个比喻并不恰当——养猫比这要容易多了。
CSS3, CSS4, and other mythical creatures
CSS3、CSS4 以及其他神秘生物
CSS 1 was a very short and relatively simple specification, published in 1996 by Håkon Wium Lie and Bert Bos. It was so small that it was all included in a single HTML page, which required around 68 sheets of A4 paper to print.
CSS 1 的规范非常短，而且相对比较简单，由 Håkon Wium Lie 和 Bert Bos 发布于 1996 年。它的内容少到用一个 HTML 页面就足以呈现了，即使用 A4 纸打印出来也只需要 68 页。
CSS 2, published in 1998, was more strictly defined, and included much more power and two more spec editors: Chris Lilley and Ian Jacobs. At this point, the length of the specification had grown to 480 (!) printed pages and was already getting too big to be held in human memory in its entirety.
CSS 2 发表于 1998 年，它的定义更加严格，囊括了更多的功能，而且增加了两名编辑：Chris Lilley 和 Ian Jacobs。此时，规范的篇幅暴增到了 480 页打印纸，以致于正常人类已经无法把它完整地记下来了。
After CSS Level 2, the CSS WG realized that the language was getting too big to be contained in a single specification. Not only was it extremely unwieldy to read and edit, but it was also holding CSS back. Remember that for a specification to advance to the final stages, every single feature in it needs at least two independent implementations and exhaustive tests. This was no longer practical. Therefore, it was decided that going forward, CSS was going to be broken into multiple specifications (modules), each with its own versioning. Those that expand on features that were already present in CSS 2.1 would have a level number of 3. For example, some of these modules are:
在 CSS 2 之后，CSS 工作组意识到这门语言已经变得非常庞大了，再也无法把它塞进单个规范中了。这样不仅阅读和编辑极其困难，而且也限制了 CSS 本身的快速发展。别忘了，一项规范如果要推进到最终阶段，其中的每项特性都必需具备两个独立的实现和全面的测试。原先的那种方式已经玩不转了。因此，我们决定跨出一步，将 CSS 打散到多个不同的规范（模块）中，每个模块都可以独立更新版本。这其中，那些延续 CSS 2.1 已有特性的模块会升级到 3 这个版本号。比如以下这些模块：
However, modules that introduce entirely new concepts start from Level 1. Here are a few examples:
此外，如果某个模块是前所未有的新概念，那它的版本号将从 1 开始。比如下面这些：
Despite the popularity of the “CSS3” buzzword, there is actually no specification defining such a thing, like there was for CSS 2.1 or its predecessors. Instead, what most authors are referring to is an arbitrary set of Level 3 specs, plus some Level 1 specs. Although there is some good degree of consensus among authors on which specs are included in “CSS3,” as CSS modules evolve at different rates over the years, it will become more and more difficult to refer to things like CSS3, CSS4, and so on and be universally understood.
尽管 “CSS3” 这个名词非常流行，但它实际上并没有在任何规范中定义过——这一点跟 CSS 2.1 或更早的 CSS 1 不一样。真正的情况是，绝大多数编辑在提到这个词时，指的是一个非正式的集合，它包括 CSS 规范第三版（Level 3）再加上一些版本号还是 1 的新规范。尽管在哪些规范应该归作 “CSS3” 的问题上，编辑们基本上是有共识的，但我们也不得不面对现实——由于 CSS 的各个模块在近些年里是以不同速度在推进的，我们已经越来越难以把这些规范以 CSS3、CSS4 这样的方式来划分了，而且这样也难以被大众理解和接受。
A story of ice, fire, and vendor prefixes
冰与火之歌：浏览器前缀
In standards development, there is always a big catch-22: standards groups need input from developers to create specifications that address real development needs. However, developers are generally not interested in trying out things they can’t use in production. When experimental technologies get widely used in production, the WG is forced to stick with the early, experimental version of the technology, to avoid breaking several existing websites if they change it. Obviously, this completely negates the benefits of getting developers to try out early standards.
在标准的开发过程中，总是有一条大大的 “第 22 条军规” 挡在面前{1[译注：《第 22 条军规》是美国作家 Joseph Heller 的作表作，这部讽刺小说被誉为 20 世纪最伟大的文学作品之一。书中提到的 “第 22 条军规” 是一条自相矛盾的、永远不可能执行的悖论。]}：标准的工作组需要网页开发者这一端的输入，以确保各项规范可以处理真实的开发需求。但是，开发者们往往没有兴趣尝试那些在生产环境中还不能使用的东西。当实验性的技术被广泛应用到生产时，工作组就被这些技术早期的、实验性的版本捆住手脚了，因为一旦这些技术有变动，那些已经在用这些技术的网站就挂了。显然，这完全否定了让开发者尝试早期标准的好处。
Over the years, many solutions have been proposed to address this conundrum, none of them perfect. The universally despised vendor prefixes were one of them. The idea was that every browser would be able to implement experimental (or even proprietary) features with their own prefix prepended to its name. The most common prefixes are
-moz-for Firefox,-ms-for IE,-o-for Opera, and-webkit-for Safari and Chrome. Developers would be able to freely experiment with these prefixed features and provide feedback to the WG, which would then incorporate this feedback into the specs and slowly perfect the design of the feature. Because the final, standardized version would have a different name (no prefix), it wouldn’t collide with the existing uses of its prefixed counterparts.这些年来，为了解决这个难题，许多方案被提了出来，但都不够完美。饱受诟病的浏览器前缀就是其中之一。这个方案是指每个浏览器都可以实现这些实验性的（或甚至是私有的、非标准的）特性，但要在名称前面加上自己特有的前缀。最常见的前缀分别是 Firefox 所用的
-moz-、IE 所用的-ms-、Opera 的-o-以及 Safari 和 Chrome 所用的-webkit-。网页开发者们可以自由地尝试这些加了前缀的特性，并把试用结果反馈给工作组，而工作组随后会将这些反馈吸收到规范之中，并且逐渐完善该项特性的设计。由于最终标准化的版本会有一个不同的名称（没有前缀），它在实际应用中就不会跟加前缀版本相冲突了。Sounds great, right? Of course, as you probably know, the reality was quite different from the vision. When developers realized that these experimental, vendor-prefixed properties could make it so much easier to create effects that previously required messy workarounds, they started using them everywhere. Vendor-prefixed properties quickly became the CSS trend of the time. Tutorials were written, StackOverflow replies were given, and soon almost every self-respecting CSS developer was using them all over the place.
听起来不错，对吧？但是，你可能也猜到了，现实距离我们的期望往往有着很大的落差。当开发者们发现这些实验性的、加了前缀的属性可以轻而易举地实现以前大费周章才能达到效果时，他们就开始撒开了用了。这些加了浏览器前缀的属性迅速成为 CSS 领域的一大潮流。网上的教程会写出它们、StackOverflow 上的问答会提到它们，很快，几乎每个有上进心的 CSS 开发者都开始争先恐后地使用它们。
Eventually, authors realized that using only existing vendor prefixes meant they would have to go back to previous work and add new declarations every time another browser implemented their favorite cool new CSS feature. Not to mention how hard it became to keep up with which prefixes were needed for what feature. The solution? Add all possible vendor prefixes preemptively, including the unprefixed version at the end, to future-proof it. We ended up with code like the following:
不久，网页开发者们就发现，在使用这些神奇的新特性时，如果只写出当下有效的浏览器前缀，就意味着以后要经常回来打补丁——每当多了一个浏览器实现了这个新特性时，他们都需要多加一行。去跟进各个特性在各个浏览器下是不是要加前缀，光是想想就让人头皮发麻。那开发者们会怎样应对？就是先发制人地加上所有可能的浏览器前缀，再把无前缀的版本放在最后，以图一劳永逸。我们最终写出的代码可能就是这样的：
Two of the declarations here are completely redundant:
-ms-border-radiusand-o-border-radiusnever existed in any browser, as IE and Opera implementedborder-radiusunprefixed from the get-go.这里面有两条声明是完全多余的：
-ms-border-radius和-o-border-radius这两个属性从来没有在任何浏览器中出现过，因为 IE 和 Opera 从一开始就是直接实现border-radius这个无前缀版本的。Obviously, repeating every declaration up to five times was tedious and unmaintainable. It was only a matter of time until tools were built to automate this:
显然，把每个声明都重复五遍是相当枯燥的，而且很难维护。因此出现某个工具来把这项工作自动化只是个时间问题：
Because authors were using the unprefixed version of features as a means to future-proof their code, it became impossible to change them. We were basically stuck with half-baked early specs that we could change in very limited ways. It didn’t take long for everyone involved to realize that vendor prefixes were an epic failure.
由于网页开发者们使用无前缀的属性是想确保代码的向前兼容，那么工作组想要修改这些无前缀语法就变得不可能了。我们基本上就跟这些半生不熟的早期规范绑在一起了，只能通过极其有限的途径来修改它们。用不了多久，这个坑里的每个人就会意识到，浏览器前缀已是一场史诗般的失败。
These days, vendor prefixes are rarely used for new experimental implementations. Instead, experimental features require config flags to be turned on, effectively preventing developers from using them in production, as you can’t really tell users to change their settings in order to view your website properly. Of course, this has the consequence that fewer authors get to play with experimental features, but we still get enough feedback, and arguably, better quality feedback, without the drawbacks of vendor prefixes. However, it will be a long time before the ripple effects of vendor prefixes stop haunting us all.
最近以来，浏览器厂商已经很少以前缀的方式来实验性地实现新特性了。取而代之的是，这些实验性特性需要通过配置开关来启用，这可以有效防止开发者们在生产环境使用它们，因为你不能要求你的用户为了正确地浏览你的网站而去修改他们的浏览器设置。当然，这会导致一个后果，尝试这些实验性特性的开发者会减少，但我们仍然会得到足够多的反馈，甚至是（你可能会质疑）更高质量的反馈，同时还避免了浏览器前缀的所有缺点。不过我们还需要很长的时间，才能从浏览器前缀所引发的涟漪效应中解脱出来。
The text was updated successfully, but these errors were encountered: