关于浏览器前缀

题引

-moz-border-radius: 10px;
-ms-border-radius: 10px;
-o-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;

了解一下浏览器前缀的历史，学习记录

摘自： 《css揭秘》

历史

与大众的理解大相径庭的是，W3C 并不“生产”标准。实际上，它扮演的是一个论坛的角色：W3C 以工作组的方式，把某项技术的相关各方聚集起来，最终由他们来产出标准。当然，W3C 并不只是一个观察者：它设定了整个平台的规则，监督整个进程。但这些技术规范（基本上）并不是由W3C 的工作人员编写完成的。

在 《css揭秘》 的作者在编写 《css揭秘》 时，CSS工作组共有 98 名成员，人员结构如下：

• 86 名来自 W3C 会员公司的成员（88%）
• 7 名特邀专家（7%）
• 5 名 W3C 工作人员（5%）

你可能注意到了，工作组的绝大多数成员（88%）来自 W3C 会员公司。这些公司（比如浏览器厂商、主流网站、研究机构、常规技术公司等）都是Web 标准兴旺发展的直接受益者。它们每年的会费也是 W3C 的主要资金来源，使得 W3C 能够免费、开放地发布所有技术规范，而不像其他标准制定组织那样不得不采取收费政策来维持运作。

特邀专家 是指那些被邀请参与标准制定的 Web 开发者。在真正获得这样的殊荣之前，他们需要证明自己在解决难题时能够持续不断地投入，在参与讨论时能够体现出深厚的技术背景。

Web 开发者们普遍存在一个误解，以为 W3C 手握标准、号令天下，这显然不是真相：对于哪些东西该进入标准，浏览器厂商比 W3C 有更多的发言权。

在标准的开发过程中，总是有大大的“第 22 条军规”挡在面前：标准的工作组需要网页开发者这一端的输入，以确保各项规范可以处理真实的开发需求；但是开发者往往没有兴趣尝试那些在生产环境中还不能使用的东西。当实验性的技术被广泛应用到生产时，工作组就被这些技术早期的、实验性的版本捆住手脚了，因为一旦这些技术有变动，那些已经在用这些技术的网站就挂了。显然，这完全否定了让开发者尝试早期标准的好处。这些年来，为了解决这个难题，许多方案被提了出来，但都不够完美。
饱受诟病的浏览器前缀就是其中之一。

这个方案是指每个浏览器都可以实现这些实验性的（甚至是私有的、非标准的）特性，但要在名称前面加上自己特有的前缀。最常见的前缀分别是 Firefox 的 -moz-、IE 的 -ms-、Opera的 -o- 以及 Safari 和 Chrome 的 -webkit-。网页开发者可以自由地尝试这些加了前缀的特性，并把试用结果反馈给工作组，而工作组随后会将这些反馈吸收到规范之中，并且逐渐完善该项特性的设计。由于最终标准化的版本会有一个不同的名称（没有前缀），它在实际应用中就不会跟加前缀版本相冲突了。

听起来不错，对吧？但是你可能也猜到了，现实与我们的期望往往有很大的落差。当开发者发现这些实验性的、加了前缀的属性可以轻而易举地实现以前大费周章才能达到的效果时，他们就开始滥用了。这些加了浏览器前缀的属性迅速成为 CSS 领域的一大潮流。网上的教程会写到它们，Stack Overflow 上的问答会提到它们……很快，几乎每个有上进心的 CSS 开发者都开始争先恐后地使用它们。

不久，网页开发者们就发现，在使用这些神奇的新特性时，如果只写出当下有效的浏览器前缀，就意味着以后要经常回来打补丁：每当又一个浏览器实现了这个新特性时，他们都需要多加一行。跟进各个特性在各个浏览器下是不是要加前缀，光是想想就让人头皮发麻。开发者会怎样应对？那就是先发制人地加上所有可能的浏览器前缀，再把无前缀的版本放在最后，以图一劳永逸。我们最终写出的代码可能就是题引那样的。

显然，把每个声明都重复五遍是相当枯燥的，而且很难维护。因此出现
某个工具来把这项工作自动化只是个时间问题。

• 像 CSS3, Please!（http://css3please.com）和 pleeease（http://pleeease.io/playground.html） 这样的网站允许你把无前缀的 CSS 代码粘贴进去，它们会自动帮你把必要的前缀都加好。这类网站是“前缀危机”所催生出的第一批工具，很快就过气了，因为跟其他方案相比，它们的使用成本太高了。
• Autoprefixer（https://github.com/ai/autoprefixer）采用 Can I Use…（http://caniuse.com）的数据库来判断哪些前缀是需要添加的；此外，它是在本地完成编译的，类似预处理器。
• 《css揭秘》 作者开发的 -prefix-free（http://leaverou.github.io/prefixfree） 会在浏览器中进行特性检测，来决定哪些前缀是需要的。它的好处在于几乎不需要更新，因为其所有信息都是用一份属性清单在真实的浏览器环境中跑出来的结果。
• 类 似 Stylus（http://stylus-lang.com/）、LESS（http://lesscss.org） 或Sass（http://sass-lang.com）的预处理器并不自带任何加前缀的方法，但很多人开发过一些能为常用属性加前缀的 mixin；社区中也有一些库提供了这类 mixin。

由于网页开发者使用无前缀的属性是想确保代码的向前兼容，那么工作组想要修改这些无前缀语法就变得不可能了。我们基本上就跟这些半生不熟的早期规范绑在一起了，只能通过极其有限的途径来修改它们。用不了多久，这个“坑”里的每个人就会意识到，浏览器前缀已是一场史诗般的失败。

最近，浏览器厂商已经很少以前缀的方式来实验性地实现新特性了。取而代之的是，这些实验性特性需要通过配置开关来启用，这可以有效防止开发者在生产环境中使用它们，因为你不能要求用户为了正确地浏览你的网站而去修改浏览器设置。当然，这会导致一个后果：尝试这些实验性特性的开发者会减少；但我们仍然会得到足够多的反馈，甚至是更高质量的反馈（你
可能会质疑），同时还避免了浏览器前缀的所有缺点。不过我们还需要很长的时间，才能从浏览器前缀所引发的涟漪效应中解脱出来。

总结

：从业两年多，参与的项目都没有兼容性方面的需求，只兼容chrome,或者chrome的早期版本，（emmmm,心情复杂），面试时被问到了渐进增强和优雅降级，随做了个了解，蛮有趣。