有很多工具可以解决浏览器前缀问题，无论是针对麻烦属性的IDE自动扩展还是使用预编译器进行混合，都是为什么浏览器制造商需要实现前缀。从我所听到的情况来看，他们可以实现自己的某些实现，但是什么阻止他们在没有前缀的情况下这样做。现在特别是几乎所有浏览器都尝试遵循W3规范，所以我怀疑Safari会制作，比如盒子阴影，在元素中画一条彩虹。
离开他们的＆＃34;解决方案＆＃34;不是更好吗？虽然可能有点错误或缺乏功能，没有前缀，所以当他们实际推出符合所有标准的工作版本时，使用该样式的JavaScript属性编写的网站可以按预期运行？我真的无法看到每个人都认为实施它们是个好主意。答案 0 :(得分：4)
想法是想要“试用”本地本地这些实验性功能的作者可以使用发货浏览器上的前缀属性，而不必处理夜间构建甚至下载和编译手动来源，因为没有前缀的出货车行为类似于将测试版软件作为生产质量出货。
供应商没有看到的是作者会采用前缀属性，将它们放在生产网站上，并且鼓励其他作者做同样的。因此，前缀像野火一样蔓延到供应商过于害怕通过在发送稳定的，无前提的实现之后删除前缀来破坏网站的程度。我的意思是，只看what happened when Mozilla dropped support for -moz-opacity，这是一个前缀属性，与今天的-webkit-属性相比，使用相对较少，小于 4年前。对于透视，-moz-opacity在Firefox 0.9 中几乎没有固定，几乎 12年前。
这个前缀惨败的另一个不幸结果是什么？ Opera，微软和Mozilla都不情愿地改变他们的CSS实现以识别-webkit-前缀，因为WebKit正在进入几乎所有移动设备和每个小众浏览器，而作者则认为WebKit是One True Layout Engine™，因此他们为WebKit 而不是其他编码。很显然，我们还没有从IE / Netscape浏览器大战中学习过。
这就是为什么供应商已经同意不再使用前缀用于未来标准的实验性实施。新的CSS功能将不加固定，但默认情况下不可用。例如，Firefox将这些功能隐藏在特殊的about：config选项后面，默认情况下会在以后启用它们，而Chrome会以类似的方式将它们隐藏在about：flags中。