javascript - 从浏览器创建者的 Angular 来看，为什么浏览器前缀是必需的

Question

有很多工具可以解决浏览器前缀问题，无论是 IDE 自动扩展麻烦的属性还是使用预编译器进行混合，但为什么浏览器制造商确实需要实现前缀。据我所知，他们可以实现自己的某些实现，但是什么阻止他们在没有前缀的情况下这样做。现在几乎所有的浏览器都试图遵循 W3 规范，所以我怀疑 Safari 是否会在元素内绘制彩虹，比如 box-shadow。

保留他们的“解决方案”虽然可能有点错误或缺乏功能，没有前缀不是更好吗，所以当他们实际推出满足所有标准的工作版本时，使用这种 JavaScript 属性样式编写的网站可以运行如预期？我真的不明白为什么每个人都认为实现它们是个好主意。

Answer 1

想法是，想要在本地“尝试”这些实验性功能的作者可以使用发布浏览器上的前缀属性来实现，而不必处理每晚构建甚至下载和编译手动获取源代码，因为不加前缀地发布 bug 行为类似于将 beta 软件作为生产质量发布。

vendor 没有预料到的是作者会采用前缀属性，将它们放在生产站点上，并鼓励其他作者也这样做。结果，前缀像野火一样蔓延到 vendor 不敢通过在按最初预期交付稳定的、无前缀的实现后删除前缀来破坏站点。我的意思是，看看what happened when Mozilla dropped support for -moz-opacity ，与今天的 -webkit- 属性相比，这是一个相对较少使用的前缀属性，少于 4 年前。从 Angular 来看，-moz-opacity 在 Firefox 0.9 中是没有前缀的，大约 12 年前。

这个前缀失败的另一个不幸结果？ Opera、Microsoft，最后是 Mozilla，都勉强地改变了他们的 CSS 实现以识别 -webkit- 前缀，因为 WebKit 正在进入几乎所有的移动设备和每个小众浏览器，而作者对此印象深刻WebKit 是 One True Layout Engine™，因此他们为 WebKit 而不是其他 编写代码。显然，我们还没有从 IE/Netscape 浏览器大战中吸取教训。

这就是为什么 vendor 同意不再对 future 标准的实验性实现使用前缀。新的 CSS 特性将不带前缀地发布，但默认情况下不可用。例如，Firefox 将这些功能隐藏在特殊的 about:config 选项后面，并在以后默认打开它们，而 Chrome 以类似的方式将它们隐藏在 about:flags 中。