为什么使用特定的供应商前缀而不是代表所有浏览器的前缀 [英] Why use specific vendor prefixes instead of one representing all browsers

问题描述

据我所知，使用供应商前缀的唯一原因是浏览器创建者引入了它们，以在根据W3C完全实施之前发布新规范.

As far as I know the only reason behind usage of vendor prefixes is that they were introduced by browser creators to release a new specification before its completely implemented according to W3C

但是为什么每个浏览器都需要一个特定的供应商前缀.

But why need a specific vendor prefix for every browser.

如果我们看以下CSS:

If we look at the following css:

.box{
   -webkit-box-shadow:0 0 1px #000;
   -moz-box-shadow:0 0 1px #000;
   -o-box-shadow:0 0 1px #000;
   box-shadow:0 0 1px #000;
}

为什么不能这样写

.box{
   -vendor-box-shadow:0 0 1px #000;
   box-shadow:0 0 1px #000;
}

每个单独的浏览器在看到前缀-vendor-时都以自己的方式实现. 由于开发人员懒于使用-ms-，并且-o-永远不会出现，因此这不仅使开发人员更容易，而且对于浏览器创建者来说也很容易，因为像Microsoft和Opera那样的情况开始支持-webkit-.如果-vendor-属于这种情况，则适用于所有浏览器.

each individual browser on seeing the prefix -vendor- implements in its own way. This not only makes it easy for developers but also for browser creators as situations like microsoft and opera compromized started supporting -webkit- because developers were lazy to use -ms- and -o- would never rise. If it was the case with -vendor- it applies to every browser.

有人能对此有所启发吗?

Can anyone throw some light on this?

推荐答案

据我所知，使用供应商前缀的唯一原因是浏览器创建者引入了它们，以在根据W3C完全实施之前发布新规范.

As far as I know the only reason behind usage of vendor prefixes is that they were introduced by browser creators to release a new specification before its completely implemented according to W3C

否； 根据W3C ，供应商前缀的目的是让供应商提供自己的实验性，专有或其他非标准功能的实现.该前缀用于标识负责此实现的特定供应商.从 CSS2.1规范:

No; according to W3C, the purpose of a vendor prefix is for a vendor to provide their own implementation of an experimental, proprietary, or otherwise non-standard feature. The prefix is meant to identify the specific vendor responsible for this implementation. From the CSS2.1 spec:

在CSS中，标识符可以以-"(破折号)或"_"(下划线)开头.以-'或'_'开头的关键字和属性名称保留用于特定于供应商的扩展名.此类特定于供应商的扩展名应具有以下格式之一:

In CSS, identifiers may begin with '-' (dash) or '_' (underscore). Keywords and property names beginning with -' or '_' are reserved for vendor-specific extensions. Such vendor-specific extensions should have one of the following formats:

'-' + vendor identifier + '-' + meaningful name
'_' + vendor identifier + '-' + meaningful name

例如，如果XYZ组织添加了一个属性来描述显示器东侧的边框颜色，则他们可能将其称为-xyz-border-east-color.

For example, if XYZ organization added a property to describe the color of the border on the East side of the display, they might call it -xyz-border-east-color.

实际上，该规范甚至没有具体提及现有或未决标准的实验性实现"，尽管其仅属于非标准"类别.无论如何.

In fact, the spec doesn't even specifically mention "experimental implementations of existing or pending standards", although that just falls under the category of "non-standard" anyway.

此外，由于供应商可以根据自己的喜好实现自己的属性，因此您不能保证每个供应商都会同意像属性语法这样简单的内容.例如，border-radius的longhand属性在Firefox中如下所示:

Furthermore, because a vendor can implement their own property however they like, you cannot guarantee that every vendor will agree upon something as simple as the syntax of a property. For example, the longhand properties for border-radius looked like this in Firefox:

-moz-border-radius-topleft
-moz-border-radius-topright
-moz-border-radius-bottomleft
-moz-border-radius-bottomleft

与WebKit有很大不同:

Which is very different from WebKit:

-webkit-border-top-left-radius
-webkit-border-top-right-radius
-webkit-border-bottom-left-radius
-webkit-border-bottom-right-radius

您可以猜到，WebKit表单是最终规格的表单，Mozilla在将border-radius提升为Firefox 4的标准时必须遵循该表单.但这是关键:这是Mozilla的原因最初使用旧名称实施的正手是因为曾经是 spec 使用的名称！因此，不仅是WebKit重命名了属性，而且CSSWG也重命名了属性，最终导致实现之间的不兼容性.

As you can guess, the WebKit form was the one that made it to the final spec, which Mozilla had to follow when they got around to promoting border-radius to standard in Firefox 4. But here's the kicker: the reason Mozilla originally implemented the longhands with the old names is because once upon a time, those were the names that were used by the spec! So it wasn't just WebKit that renamed the properties, but the CSSWG as well, which ultimately led to an incompatibility between implementations.

为所有实验实现使用单个前缀没有多大意义，因为那样的话，您最好让每个人都实现不带前缀的属性，而不必不必要地复制它或"unprefix".以后再说.即便如此，您仍然面临上述不断发展的标准和实现不兼容的问题.

There isn't much of a point in having a single prefix for all experimental implementations, because then you might as well just have everyone implement the property without the prefix and save having to needlessly duplicate it or "unprefix" it later. And even then, you still have the aforementioned problem of evolving standards and implementation incompatibilities.

WebKit前缀的问题仅源于供应商和作者对前缀的广泛滥用(多数情况下，作者选择只使用-webkit-，而忽略了其他人，这要归功于Chrome和其他工具的普及).浏览器供应商找到了一种更好的方法来处理此问题，这使他们可以完全放弃前缀 ，例如将实验性属性隐藏在用户界面的兼容性标志后面.

The problem with WebKit prefixes simply stems from a widespread abuse of prefixes by both vendors and authors (mostly with authors choosing to only use -webkit- and ignoring others thanks to the popularity of Chrome and whatnot). Browser vendors have found a much better way to deal with this which allows them to abandon prefixes altogether, such as hiding experimental properties behind compatibility flags in their UI.

请注意，前缀仍用于其原始预期目的；例如，Microsoft将-ms-用于各种WinRT组件的CSS实现，而Mozilla将-moz-用于XUL的CSS实现，该XUL用于实现Firefox的UI.

Note that prefixes are still used for their original intended purpose; for example Microsoft uses -ms- for CSS implementations of various WinRT components, and Mozilla uses -moz- for CSS implementations of XUL, which is used to implement Firefox's UI.

这篇关于为什么使用特定的供应商前缀而不是代表所有浏览器的前缀的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！