如果您编写 CSS,几乎肯定需要在您编写的某些代码部分使用供应商前缀,以确保最佳的浏览器支持。无论是 -prefix-transform 之类的带前缀的属性,还是 @-prefix-keyframes 之类的带前缀的 @规则,或者 -prefix-linear-gradient 之类的带前缀的值,这都是 CSS 作者的日常工作。
这不仅是我们工作的一部分,而且也很容易出错。我最近查看了许多大型网站,专门寻找一些细微的 CSS3 错误,我能够在查看的任何网站上都找到一个。
那么,我们如何编写 CSS,才能始终使用正确的供应商前缀呢?
手动编写 - 参考 CSS3Please
手动编写是指您的网站在生产(“实时”)中使用的 CSS 是您在文本编辑器中自行编辑的 CSS 文件。选择此方法意味着您需要在该已编写文件中自己包含所有正确的供应商前缀。对我来说有点乏味且容易出错,但可能是世界上大多数网站的可能情况。
如果您的情况如此,最好的方法是参考最新的资源,例如 CSS3 please!。您可以在该网站上直接编辑值,并将其复制粘贴到您自己的样式表中。

如果您这样做,则意味着 **责任在于您** 要 保持内容更新。供应商前缀不像以前那样不稳定,但每隔几个月查看一次肯定是有必要的。
手动编写 - 不使用前缀 - 让 -prefix-free 在客户端处理
您仍然手动编写 CSS,但您只使用不带前缀的属性/值/@规则。 -prefix-free 是一段 JavaScript 代码,它运行时会查看所有 CSS,并在页面上追加新的样式,其中包含使这些样式生效所需的正确前缀(如有必要)。
这是一个备受争议的话题。它使 CSS 文件更小!是的,但它存在未应用 CSS3 样式的元素闪烁的风险!它需要使用 JavaScript 来设置样式,这会造成冲突!是的,但它只有 2k!由于它会在浏览器不再需要前缀时停止添加前缀,因此它是渐进增强功能的最佳体现!

由您决定。
还值得注意的是,jQuery 的 .css()
方法 将为您 添加一些前缀。
$("body").css({
// Will NOT prefix
"background": "linear-gradient(#ccc, #666)",
// Doesn't need to, so won't
"box-shadow": "inset 0 0 5px black",
// WILL prefix
"transform" : "rotate(5deg)"
});
我通常不赞成通过 JavaScript 应用 CSS,但了解这一点很重要,因为规则总有例外。
手动编写 - 使用 Prefixr 修复
如果您不喜欢手动编写前缀,但最终您的工作流程部署了手动编写的 CSS,则可以在部署之前通过 Prefixr 运行您的 CSS。它本质上会解析您的 CSS,查找需要添加前缀的内容,并为您添加前缀。
它非常智能,您不必拥有专门不带前缀的 CSS(例如 -prefix-free 所需的)。例如,如果您碰巧缺少三个必需的前缀之一,它会看到并只添加缺少的那个。

它还可以通过命令行或流行的文本区域 添加到工作流程中。
预处理 - 使用 mixin
使用 CSS 预处理器的一个主要原因是它可以帮助处理供应商前缀。
如果您使用 Sass,Compass 或 Bourbon 为您提供了强大的 CSS3 mixin 集。

如果您使用 LESS,我有一套,或者您可以查看 这篇汇总文章,其中比较了一些其他的 mixin 库。
手动编写 - 不使用前缀 - 使用 Autoprefixer 后处理
这是一种非常好的方法。 这篇文章中详细介绍了。本质上,您只需忘记添加前缀,此构建步骤将根据来自 CanIUse 的最新信息为您添加前缀。
“不要做”
我偶尔会看到一个错误,即人们在每个 CSS3 属性上都使用所有主要的前缀。他们似乎有一个通用的 mixin,他们只是将所有内容都通过它,并添加前缀。如果您看到类似 -o-border-radius
的内容,那就是我的意思。它从未存在过,也不需要添加到您的 CSS 中。
另一个错误是让 CSS 过时。正如我之前提到的,值得查看一下几个月前的 CSS,以确保它没有过时。如果您在此网站上看到任何过时的内容,请告诉我,我会立即更新。
我认为处理前缀的最佳预处理器工具是与 Stylus 一起使用的 NIB。您不需要像那些难看的 Compass mixin 那样使用特殊的语法。您可以编写纯 CSS,Stylus 会将其解释为 mixin 并生成正确的供应商前缀。
http://visionmedia.github.com/nib/
compass mixin 并没有那么难看,而不是
-你做-
仍然非常相似
Bourbon 也是一样 :P
NIB 的处理方式很有趣。我可以理解任何一方的论点。我有点喜欢它变得多么简单。就像“帮我搞定吧,电脑!”另一方面,明确地知道何时需要电脑帮助以及何时不需要电脑帮助也很不错。@include 允许这种明确性。
我真的认为是时候停止添加前缀了。这绝对是一件毫无道理且无用的事情。
很棒的工具。这确实是一次痛苦的经历,人们经常会忘记某些样式的某个供应商前缀。“手动编写”工具是我首选的方式。我不用担心任何事情 :)
在阅读了这篇文章后,我认为我们甚至不再需要前缀(浏览器特定的 hack):https://css-tricks.cn/do-we-need-box-shadow-prefixes/
我是 Lea Verou 的 prefixfree 及其相关插件的忠实粉丝。只要通常将代码编写成优雅降级即可。在没有 JavaScript 的环境中,您可能也处于无法识别使用 CSS 应用的渐变和阴影等内容的环境中。
Prefixr 看起来是另一个很棒的解决方案,但我还没有使用过。也许我可以在编码/使用实时重载时使用 prefixfree,然后删除链接并在编码完成后通过 Prefixr 运行 CSS。
-ms-border-radius
怎么样?不存在。
感谢这些提示!
我非常喜欢Prefixr,特别是因为我大部分的HTML和CSS编辑工作都在TextMate和Chrome中进行,并在之后进行跨浏览器测试。这样,我在编码时只需要关注webkit前缀,并在准备好测试其他浏览器时让prefixr自动处理其余部分。
嗨,
感谢提及-prefix-free!一个小小的细节:-prefix-free不需要你完全不使用前缀。如果你添加了某个前缀,它会保持原样,不会以任何方式更改它。
感谢澄清!
致所有人
如果你希望-prefix-free帮助你添加前缀,你必须保持代码不带前缀。
如果你想自己控制前缀,尽管去做,-prefix-free不会干扰它们。
这意味着我可以同时使用Compass和-prefix-free来捕捉我可能遗漏的任何内容吗?
在这个阶段,我认为CSS3必须被视为一种增强功能。我不喜欢交付一个充满了前缀的设计——很可能永远不会更新——而且我懒得也不想一直更新我自己维护的网站。这就是我如此喜欢prefix-free的原因。非常感谢,Lea。
在从LESS迁移到SASS之前,我编写了自己的mixin或包含了一些我在网上收集的代码片段。由于没有LESS版本的Compass变体,你就会暴露在这些前缀带来的丑陋和臃肿的CSS中。我使用时非常谨慎,因为我知道幕后真正发生的事情。
现在有了Compass,我不必考虑这些丑陋的东西了——它会完成这些脏活累活。它购买笨重的袋子和在内华达州的沙漠里挖洞。我不再问问题了。但偶尔我会偷瞄一下编译后的CSS,然后感到不寒而栗。
最终,我选择了便利的路线,只是让预处理器来做这件事。它消除了我自己手动编码的潜在错误,而且至少Compass尝试只实现现实情况下真正需要的那些前缀,而不是像你的“不要”总结的那样添加所有可以想象到的前缀。你只需要确保Compass保持最新即可。
总有一天(可能永远不会)我会重新审视这个选择,并再次选择便利性。
一如既往地优秀!
我不理解的是,为什么Sass和LESS需要使用mixin来添加前缀。如果能够编写标准的CSS并自动添加所需的前缀,那就好多了。
关于CSS3Please的一点说明:他们放弃了对IE8的支持(IE8仍然被大约10%的用户使用),所以请记住这一点。
放弃IE8支持这一点很有意思,感谢你的提醒。
但是大家要注意:不要根据你在某个地方看到的“10%”来做出决定。你应该永远只根据从自己的网站收集到的数据来做出决定。
你的意思是放弃了CSS3Please在IE8中工作的支持,还是放弃了它输出的前缀中对IE8的支持?假设是前者,那谁在乎呢?我很难相信他们统计数据中10%是IE8。
关于“不要”——我认为你应该为潜在的未来属性添加前缀,例如,当Opera根本不支持
border-radius
时,绝对应该包含-o-border-radius
以备将来使用。我绝对不同意。那个带前缀的属性从未存在过,也永远不会存在。因为你认为它将来可能存在而包含它是一种我无法支持的奇怪的预优化。
我认为,如果你的项目很小,那么一个简单的mixin可以将所有CSS3属性都加上所有供应商的前缀,这可能是可以接受的。就像inuit.css中使用的那个一样。
我只是觉得这种做法不太舒服,这就是我唯一想说的。
Clearless是一个非常棒的LESS mixin库。它处理前缀问题以及许多其他很酷的功能。
是的!-prefix-free太棒了。
我使用Sublime Text的Prefixr插件,它在添加我可能遗漏的任何前缀或删除不再需要的那些前缀方面做得非常好。我从来没有真正检查过它是否总是最新的,但它确实按广告宣传的那样工作。
我必须为ST2的Prefixr点赞,我经常使用它,以及LESS mixin。
我工作的地方的代码规范——经过了大量的讨论和更新——要求在任何带前缀的属性上都使用所有主要的前缀。其理由是,以尽可能一致的方式确保覆盖所有基础并就此止步是最高效的时间利用方式,并且花时间确定任何给定属性当前需要哪些前缀并没有什么好处。务实胜过预优化。
花时间做这件事有什么好处?我想我一定遗漏了什么。
在学会使用Compass之前,我经常使用CSS3 Please。这还不错,因为我主要使用CSS3进行一些次要的增强,在较低版本的浏览器中不会真正被错过。现在我依赖Compass mixin,因为我厌倦了维护自己的mixin。在偶尔需要再次编写原生CSS的情况下,我使用Prefixr Sublime Text插件来解决这个问题。
如果我不使用任何供应商前缀,box-shadow、border-radius等在我的Firefox、Chrome、Safari、IE9中都能正常工作。那为什么要费心使用它们呢?
我认为这是另一个讨论点,渐进增强是一种方法,但使网站具有前缀跨浏览器兼容性是另一种方法。
很棒的文章,感谢Chris!读完之后,我想尝试一下Prefixr,但除了那里显示的默认代码之外,我无法让它工作。可惜,因为它听起来像一个很棒的工具。
好的,我收回之前的话,事实证明它无法处理我的样式表的顶部。所以第一行需要是一个实际的样式。
如果你也希望与Internet Explorer兼容,那么Compass是所有工具中最好的。例如
https://gist.github.com/4410998
Prefix-free和Prefixer无法做到这一点。
我想我现在会使用prefixr。即使预处理器可能是“更简单”的工作方式。也就是说。如果一个人倾向于依赖“魔法”,他可能会忘记如何正确地编写css3……所以我的建议是:对于初学者来说,就像编写标准css一样,把所有东西都写出来。那些了解技巧的人可以使用他们想要的任何工作流程来简化他们的工作……我只是知道在两年后,可能会有完全不同的方法在那个特定时间成为最佳方法。
不过文章读起来不错;) 现在就去prefixr看看我css水平到底有多差:d
由于某种原因,Prefix-Free在WordPress中无法正常工作。
那里肯定还有其他问题。我保证WordPress不在乎你在主题中使用什么JavaScript内容。
今天读到的第一篇非常有用的帖子,太棒了兄弟
致敬
Diseño Web Colombia</ a>
Giuseppe Lidonnici