以下内容摘自《CSS揭秘》一书　

　在标准的开发过程中，总是有大大的"第22 条军规"1①挡在面前：标准的工作组需要网页开发者这一端的输入，以确保各项规范可以处理真实的开发需求；但是开发者往往没有兴趣尝试那些在生产环境中还不能使用的东西。当实验性的技术被广泛应用到生产时，工作组就被这些技术早期的、实验性的版本捆住手脚了，因为一旦这些技术有变动，那些已经在用这些技术的网站就挂了。显然，这完全否定了让开发者尝试早期标准的好处。

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

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

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

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

　　这里面有两条声明是完全多余的：-ms-border-radius 和-o-border-radius 这两个属性从来没有在任何浏览器中出现过，因为IE 和Opera 从一开始就是直接实现border-radius 这个无前缀版本的。

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

　　■ 像CSS3, Please!（http://css3please.com）和pleeease（http://pleee-ase.io/playground.html）这样的网站允许你把无前缀的CSS 代码粘贴进去，它们会自动帮你把必要的前缀都加好。这类网站是"前缀危机"所催生出的第一批工具，很快就过气了，因为跟其他方案相比， 它们的使用成本太高了。

　　■ Autoprefixer（https://github.com/ai/autoprefixer）采用Can I Use... （http://caniuse.com）的数据库来判断哪些前缀是需要添加的；此外， 它是在本地完成编译的，类似预处理器。

　　■ 我自己开发的 -prefix-free（http://leaverou.github.io/prefixfree）会在浏览器中进行特性检测，来决定哪些前缀是需要的。它的好处在于几乎不需要更新，因为其所有信息都是用一份属性清单在真实的浏览器环境中跑出来的结果。

　　■ 类似Stylus（http://stylus-lang.com/）、LESS（http://lesscss.org） 或Sass（http://sass-lang.com）的预处理器并不自带任何加前缀的方法， 但很多人开发过一些能为常用属性加前缀的mixin；社区中也有一些库提供了这类mixin。

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

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

冰与火之歌：浏览器前缀