css 前缀_CSS供应商前缀和标志

css 前缀

Many CSS modules remain in draft mode at the W3C, and will continue to be for some time to come. Meanwhile, browser developers are hungry to use proposed CSS properties. At the same time, they are very aware that the proposed implementation for any property currently in draft could change as the specification is hammered out.

W3C上许多CSS模块仍处于草稿模式，并且还会持续一段时间。 同时，浏览器开发人员渴望使用建议CSS属性。 同时，他们非常了解，随着规范的制定，目前草案中任何财产的拟议实施方式都可能发生变化。

The industry's initial response to this was to implement draft CSS properties with proprietary vendor prefixes unique to each browser. The main browser prefixes are:

业界对此的最初React是使用每个浏览器唯一的专有供应商前缀来实现CSS属性草稿。 浏览器的主要前缀是：

Prefix	Browser	Example
-moz	Firefox	-moz-border-radius: 5px;
-o	Opera	-o-transition-delay: 5s;
-webkit	Safari / Chrome	-webkit-mask-image: url(circle.svg)
-ms	Internet Explorer 9+	-ms-transform-origin: centre;

字首	浏览器	例
-moz	火狐浏览器	-moz-border-radius: 5px;
-o	歌剧	-o-transition-delay: 5s;
-webkit	Safari / Chrome	-webkit-mask-image: url(circle.svg)
-ms	Internet Explorer 9+	-ms-transform-origin: centre;

(Note that there are many more vendor prefixes than those listed above, but you will find that the others are rarely called upon.)

(请注意，供应商前缀比上面列出的要多得多，但是您会发现很少需要使用其他前缀。)

The intention of vendor prefixes was to allow each browser to create its own interpretation of a proposed CSS property; when the property enters "final" status with the W3C, it is a simple change for browser vendors to drop their prefix in favour of the final version.

供应商前缀的目的是允许每个浏览器为提议CSS属性创建其自己的解释 ； 当该属性在W3C中进入“最终”状态时，对于浏览器供应商来说，删除其前缀以支持最终版本是一个简单的更改。

The value for a vendor-prefixed CSS property is often (but not always) the same between browsers: border-radius, shown below, is a good example.

供应商前缀CSS属性的值在浏览器之间通常(但并非总是)相同：如下所示的border-radius是一个很好的示例。

As a rule, vendor prefixed properties are written first in any style declaration, with the final version of the property at the end:

通常， 在任何样式声明中都首先写入供应商前缀的属性 ，最后是该属性的最终版本：

div#mainbox {
	-moz-border-radius: 5px; 
	-webkit-border-radius: 5px; 
	border-radius: 5px;
}

Because declarations are read left-to-right, browsers that drop prefixes will ignore those properties and follow the final version.

因为声明是从左到右读取的，所以删除前缀的浏览器将忽略这些属性并遵循最终版本。

As browsers are updated, more will support the final version of the property, making prefixed code increasingly redundant. border-radius typifies this; like many CSS properties, it no longer needs to be prefixed for production.

随着浏览器的更新，更多的支持该属性的最终版本，从而使前缀代码变得越来越多余。 border-radius代表了这一点； 像许多CSS属性一样，它不再需要为生产加上前缀。

It can be difficult to track which browser versions require prefixes, and when they no longer do so. Preprocessors can help with this, as can sites like Should I Prefix and Can I Use.

可能难以跟踪哪些浏览器版本需要前缀以及何时不再需要前缀。 预处理程序可以帮助解决此问题，例如“ 我应该前缀”和“我可以使用”之类的网站也可以提供帮助。

CSS的逐步增强 (Progressive Enhancement in CSS)

It’s important to understand that vendor prefixes should be considered an enhancement to a page, rather than a requirement. A browser that doesn’t support box-shadow should still receive the same information as one that does, and present it in a readable format: it will just display the data slightly differently.

重要的是要理解，应该将供应商前缀视为页面的增强 ，而不是要求。 不支持box-shadow浏览器仍应接收与支持box-shadow的信息相同的信息 ，并以可读的格式显示它：它只会稍微不同地显示数据。

供应商前缀的局限性 (The Limitations of Vendor Prefixes)

Vendor prefixes were an imperfect answer to the challenge of moving web standards forward, and generated several counter-productive behaviours in developers:

供应商前缀不能完全解决向前推进的Web标准的挑战，并在开发人员中产生了一些适得其反的行为：

• The rapid adoption of Chrome and mobile Safari, combined with developer ignorance, led many web designers to concentrate on –webkit- prefixes, leaving other browsers with equal support out in the cold.

  Chrome和移动Safari的Swift采用，再加上开发人员的无知，导致许多Web设计人员专注于–webkit-前缀，而其他浏览器却受到同等的支持。

• Prefixed code complicates stylesheets, making CSS more difficult to build. Researching which browser versions need prefixes adds significantly to development time.
  前缀代码使样式表复杂化，使CSS更加难以构建。 研究哪种浏览器版本需要前缀会大大增加开发时间。
• Developers sometimes neglect to include the final version of the property at the end of the declaration, further slowing the drive to a final spec.
  开发人员有时会忽略在声明末尾包含该属性的最终版本，从而进一步降低了最终规范的驱动力。
• Prefixes linger in stylesheets long after browsers have passed them by, making sites more difficult to optimize and maintain.
  前缀在浏览器通过后很久就留在样式表中，这使得站点更难以优化和维护。

• Other developers take a “prefix all the things” approach to CSS, adding them when they are not needed and aimlessly expanding their stylesheets. Redundant -ms- prefixes are a good example of this: Microsoft often went directly to the final version of the CSS property in IE10, with no intervening prefixed step.

  其他开发人员对CSS采用“万物前缀”的方法，在不需要它们时将其添加，并且漫无目的地扩展其样式表。 冗余的-ms-前缀就是一个很好的例子：Microsoft经常直接使用IE10中CSS属性的最终版本，而没有中间的前缀步骤。

解决方案 (Solutions)

Vendor prefixes were a well-intentioned and somewhat successful effort at progress, but came with unanticipated costs. Developers responded by trying to simplify prefix coding: Lea Verou’s -prefix-free, Sass auto-prefixed code with the appropriate mixins, and the prefixr utility all attempted to address the complex issues of generating and maintaining vendor prefixed code.

供应商前缀是一个很好的意图，并且在取得进展方面取得了一定的成功，但是却带来了无法预料的成本。 开发人员通过尝试简化前缀编码来做出回应：Lea Verou的-prefix -free ，具有适当mixins的Sass自动前缀代码以及prefixer实用程序都试图解决生成和维护供应商前缀代码的复杂问题。

Long-term, the industry appears to be moving from prefixes to a flags approach, whereby individual users have the ability to turn “beta” features on and off in their own browsers. (To see an example of this, type about: flags into the URL bar in Chrome). This will simplify work from the developer's point of view, at the potential cost of less experimentation, as it will mostly be developers who are setting flags, not casual site visitors.

从长远来看，该行业似乎正在从前缀转变为标记方法，从而使单个用户能够在自己的浏览器中打开和关闭“ beta”功能。 (要查看此示例，请在Chrome的网址栏中输入about：标志 )。 从开发人员的角度来看，这将简化工作，并减少试验的潜在成本，因为主要是设置标志的开发人员，而不是临时站点的访问者。

翻译自: https://thenewcode.com/217/CSS-Vendor-Prefixes-and-Flags

css 前缀