CSS 工作组联合主席 Daniel Glazman 告知我们，非 WebKit 浏览器供应商正在 考虑除了他们自己的前缀之外，还支持 -webkit- 前缀用于某些 CSS 功能。
特别是 Mozilla，他们目前对实验性功能使用 -moz- 前缀，在谈到他们应该使用 -webkit- 前缀支持多少功能时表示“零不是选项”。 Daniel 呼吁开发人员和布道者停止懒惰/疏忽，使用所有正确的供应商前缀，而不是仅仅使用 -webkit-。
Remy Sharp 表示 这是一个坏主意，因为它会影响开发人员的预期，并且可能会让我们在使用前缀方面变得更加懒惰。
其他反对这一不好的想法的人包括：Rachel Andrew、Bruce Lawson 和 Gilles Vandenoostende。
Christian Heilmann 表示，我们作为开发人员让自己陷入了这种困境，所以让我们解决它。
Aaron Gustafson 恳求我们 至少修复我们自己的问题，并创建了一个 反对其他供应商支持 -webkit- 的请愿书。
Eric Meyer 非常确定我们不会赢得这场战斗。
需要帮助正确添加前缀？可以使用 Prefixr、Prefix-free、CSS3 Please，或 使用预处理器。
Chris，你对此有什么看法？
真的，我感到很惊讶。
我想知道有多少以 Firefox 作为主要浏览器的人浏览的网站因为缺少 -moz- 前缀而损坏且无法使用？我猜：几乎没有。
如果 Firefox 11 开始支持 -webkit- 呢？这难道不意味着更多网站将运行得更好吗？有什么不好的呢？
我想答案是，就像 Remy 所建议的那样，这是一个长期的、思想的较量。如果浏览器供应商这样做最终导致更多网站在使用前缀方面变得懒惰，那将是一件坏事，而且确实有可能发生。
也可能即使供应商这样做，所有这些戏剧性的事情最终也不会那么严重。
如果我被要求展望未来，我会说：这是一个坏主意，不要这样做。
与其让其他浏览器都支持
-webkit-，为什么不加强对无前缀代码的支持呢？这似乎比将其他供应商硬塞进另一个供应商前缀更有意义。我完全同意。支持 W3C 标准，而不是更多前缀。
在大多数情况下，他们不能仅仅“开始支持标准”，因为没有最终的标准可供支持。这就是前缀的全部意义所在。浏览器供应商领先于标准化，发布尚未完全标准化的功能。这样，就可以从真实的网页作者那里获得反馈，当标准完成的那一天到来时（这需要浏览器实现），他们就不会从头开始。
为什么没有人想到为所有浏览器使用相同的语法前缀？如果我们去掉 -moz -webkit -o -ms，只对每个浏览器使用某个通用的前缀，那么就不会出现这个问题，对吧？
我同意 Christopher 的观点。为什么不直接使用
-x-box-shadow、-x-linear-gradient等？如果存在不兼容的实现，只需列出两者，浏览器使用它识别的任何一个即可。问题解决！那为什么不直接使用
box-shadow和linear-gradient呢？因为属性的实际名称尚未达成一致。
例如
-webkit-border-top-right-radius: 20px;
-moz-border-radius-topright: 20px;
是的，这对浏览器供应商来说是个愚蠢的想法。一直都有糟糕的开发人员。在过去，糟糕的开发人员制作的网站只在 IE 中有效。Mozilla 没有改变他们的浏览器使其像 IE 一样工作，他们坚持使用 Web 标准。现在，他们应该坚持使用他们自己的供应商前缀，一旦属性无需供应商前缀即可支持，所有这些问题都会自行解决。
Mozilla 在各种方面都改变了他们的浏览器使其像 IE 一样工作。innerHTML 支持，确认。document.all 支持，确认。嗅探 text/plain 内容（没有 IE 那样彻底，但有一些），确认。
如果不这样做，它将无法被实际用户使用。
现在，使用 -webkit 前缀属性的情况也是如此。显然，不需要支持所有这些属性，但对于任何试图成为手机浏览器的人来说，支持一些常用的属性是必须的。
相关推文
我认为应该为实验用途提供一个前缀，例如：“-exp-” 或类似的东西，然后对于常用的前缀，移除浏览器前缀；我不明白为什么 text-shadow 没有前缀，但 box shadow 需要前缀。
因为如果我没记错的话，text-shadow 来自 CSS2。Box-shadow 直到最近才一直有供应商前缀（我相信 Gecko 和 WebKit 的当前版本不再需要它），因为它是一个实验性的 CSS3 功能。现在它已经成熟，较新的版本去掉了前缀。
网站使用有前缀的属性而不包含“真实”属性是不好的做法，浏览器供应商不应该鼓励这种做法。人们只需要更新他们的浏览器而不是使用 Firefox 3.6。
有什么可以阻止 W3C 加快速度吗？我们都同意它们很慢，有什么机制可以用来加快它们的步伐吗？也许可以要求规范在 2 年后制定并继续前进。
是的，浏览器供应商阻止了 W3C 加快速度。
这个问题让我想起了 -webkit 如何实现渐变以及 -moz 如何实现渐变。
-moz 以一种比 -webkit 更“易读”的方式实现了 CSS 渐变。
转向使用一个前缀是否会像我们在 CSS 渐变中遇到过的那样，导致人们在思考编写 CSS 的“更好”方式时变得懒惰？
问题是我们有所有这些浏览器和版本来显示一个互联网。开发人员有责任确保 Web 开发能够存在，否则他们有什么用？FF 和 IE 不应该推动 ‘-webkit’ 渲染，而应该让所有浏览器推动一个 ‘-we-still-can’t-figure-this-shit-out-yet’ 标准化的“实验性/尚未标准化”前缀。
我属于“这不好”阵营。我确实对供应商前缀没有任何意见，尽管我乐于表达记住4种不同的渐变语法或为了实现圆角而重复输入相同内容6次的痛苦程度。不过我都会认真地去处理所有问题。
然而，供应商特定前缀的目的是仅仅是供应商特定，从而避免需要对CSS进行hack。它也没有真正解决手头上的真正问题。我甚至不满意-web-kit对某些属性有多种语法。
我们忘记了这些前缀真正使用的原因：所有这些属性都是草案。因此，支持、渲染和语法不仅因供应商而异，而且在某些情况下也因版本而异。
在我看来，moz复制webkit需要一些协调，我希望他们能将精力投入到标准化最终代码上。这是针对使用“-exp”的强烈抗议做出的回应。由于用户代理在支持和渲染以及解释方面存在差异，因此使用单个前缀与完全删除前缀没有区别。
这些前缀仅用于实验性功能，或者应该如此，如果有人对它们表示担忧，我认为CSS社区应该推动CSS3标准化。
迄今为止，浏览器开发者之间存在分歧，而遭受其苦的是网页开发者和用户。
是时候改变这种状况了吗？
为什么不为所有浏览器设置一个唯一的非专有前缀呢？
比如
-feature-position: center让浏览器开发者来统一这种情况。
现在，使用谷歌翻译;-)
到目前为止，浏览器开发者之间存在分歧，而遭受其苦的是网页开发者和用户。
是时候改变这种状况了吗？
为什么不为所有浏览器设置一个唯一的非专有代码呢？
比如
-feature-position: center让浏览器开发者来统一这种情况。
我想我属于少数派，除了让我的CSS看起来很丑之外，我对供应商前缀没有太多意见。
感觉我记得在某个地方见过这个建议，但我希望看到一个中间前缀（称为-wd [工作草案] 或-beta 或-exp 或其他）。
这样，浏览器就可以继续在其自己的前缀范围内实现新功能。一旦功能足够成熟可以通用化，但尚未开发到可以在规范中声明的程度，所有浏览器都可以共享一个beta等效项。当它们（最终）正式发布时，再向下传递。
我认为即使是懒惰但走在技术前沿的开发者也不会介意
-webkit-opacity: x;
-wd-opacity: x;
opacity: x;
这似乎很好地遵循了渐进增强原则。
仁慈的独裁者确实存在，这就是为什么独裁统治不一定是坏事。
将WebKit的统治地位比作IE6黑暗时代的人完全没有抓住重点。IE6之所以糟糕，是因为微软沾沾自喜。他们摧毁了竞争对手，并千方百计地损害网络创新。
WebKit不是Internet Explorer。WebKit接收来自多个来源的代码，并由独立机构管理。不仅如此，最重要的是它是开源的。
Google、Apple和其他WebKit贡献者热爱互联网。暂且忽略供应商前缀问题，WebKit引领网页浏览器标准的步伐难道是一件坏事吗？我个人更愿意这样，而不是一直等待W3C。
我个人更愿意根本不必使用供应商前缀，但要做到这一点，我们需要W3C的速度提高1000倍。
我们有事实上的标准。我们真的还需要供应商前缀吗？唯一的原因是，为了向这些年发布的浏览器提供向后兼容性，我们还需要使用它们很长一段时间。未来很糟糕。
这是个好消息。
好消息？
对我来说，不是啊。
这将影响网页开发的未来……
我希望这里的评论能引起CSS工作组的注意……
我们只是不同意。
我完全同意Kseso的观点，简单至上。
我个人对使用所有供应商前缀+标准规则没有任何问题。代码丑陋——是的。额外行数——是的。向后兼容性？是的。就像我将我的蹩脚IE过滤器分离到单独的样式表中一样，我使用所有供应商前缀。这对我来说没什么大不了的，它确保我的网站无论浏览器实现的是前缀还是标准语法都能正常工作。这没什么难的，伙计们。如果你曾经为IE6开发过，那么这与之相比就是小菜一碟。即使一些浏览器发布周期很快，我们也不应该假设每个人都在按照应有的方式更新。为什么对向后兼容性如此大惊小怪？当然他们应该使用标准语法，但他们没有。别再装腔作势了，直接使用所有前缀+标准语法。问题解决。
我宁愿遵循标准，仅在必要时使用前缀，如果不起作用，则提供一个优雅的回退方案。
我同意Garrett的观点。
是的，使用供应商前缀有点麻烦，但并不难。而且我们可以让网站按照我们想要的方式显示和工作。
正如他所说，与我们过去为了支持IE6而经历的挣扎相比，这确实是小菜一碟。
我总是想到实施另一个供应商的功能集所浪费的人力。
现在是2012年，两个主要的浏览器引擎都是开源的，但我们还没有标准化？
在开发链的各个层面都是浪费时间、精力和资源。
这促使我摆脱了“浮华模式”。
而不是像
我将使用
当然，它目前在任何浏览器中都不会起作用（？），但它实际上会让我的网站通过复古的方式显得与众不同。我不记得我上次访问一个新网站是什么时候了，它没有使用花哨的淡入淡出、过渡效果等等。
关键在于：为了在你的盒子周围实现圆角，是否值得为此编写代码、在整个互联网上进行争论以及在你的大脑中产生哲学上的痛苦？去他的吧……如果这就是现状……那就用方形边框吧！
不过圆角
很高兴看到一些关于此的讨论，因为随着CSS3的成熟，它正在成为一个问题。无论是像http://felipe.wordpress.com/2012/02/02/a-proposal-to-drop-browser-vendor-prefixes/这样的声明
还是将前缀组合成一个实验性前缀，对我来说，这听起来比列出每个语句的变体更像是进步。
在任何其他编码情况下，对于相同操作编写5行几乎相同的代码都被认为是错误，但在这里，它被认为是前沿技术。
允许Moz读取Webkit前缀将彻底扼杀Moz未来的任何开发，当他们不再需要它时，谁会添加它呢？多年来，Mozilla通过他们的前缀贡献了一些很棒的东西。
还有……（我知道我在抱怨）除非Opera和Microsoft也这样做，否则这个问题将不会得到解决，只会更加混乱。
无论如何，发展过程都会很有趣。
Paul Ferguson说得很好，我同意他的观点！
我确实喜欢“浏览器应该做X。就是这样，问题解决了。”类型的评论。在它们的过度简化方面，与那些（出租车司机是经典例子）总是夸夸其谈“如何让经济重回正轨……”的人非常相似。
【免责声明：我在一家浏览器制造商工作，但这是我个人的意见/观点。我不是这方面的专家，只是根据我的观察发表意见】
现实情况是：这个烂摊子没有简单的解决方案。供应商前缀是一种机制，允许不同的浏览器尝试并测试他们的想法。不同的浏览器会尝试不同的方法（请参阅渐变语法混乱以了解一个很好的例子）。只有从实际实施这些实验性功能中获得的经验才能制定出最终的规范，以确保这些提议实际上是可实现和可行的。
其他时候，浏览器实际上使用供应商前缀机制来发明完全专有的构造，而没有实际打算将其提交到标准化表格中。是的，在某种程度上，他们用供应商前缀的白手帕遮蔽了他们的专有内容，但他们仍然将其推送到互联网上。
然后，开发者开始在生产环境中使用这些实验性功能（通常是因为标准化过程很慢，因为浏览器在确切的语法/用途上达不成一致）。大量的网站开始使用带有前缀的版本……事实上，即使某个功能已经标准化，浏览器（是的，甚至 Webkit 本身）也无法再放弃带有前缀的版本了，因为这会导致一夜之间破坏专门为此编码的网站。当带有前缀的版本与最终版本具有不同的语法时，情况会变得更加复杂……浏览器最终不得不同时支持两者。
事后看来（事后诸葛亮总是最厉害的），浏览器或许应该只在实验室/测试版/Aurora/或任何其他版本中使用供应商前缀，而不是在稳定版本中使用。这将使它们能够实现和测试某个功能（首先是可行性，然后是作者……但必须承认，只有那些勇敢到运行实验室等版本的用户）。但是，这并不能给他们带来实际的赞誉和市场优势，所以……这种情况并没有发生。
事后看来，开发者应该比在生产环境中使用实验性/不稳定的 CSS 更明智。他们现在在网络上创建了如此多的遗留内容（并且现在不太可能回到这些网站并更改为无前缀的 CSS，因为一旦某个功能稳定下来，Webkit 会无限期地支持旧的 -webkit 版本，那么有什么问题呢？），以至于网络环境已经被污染得无法挽救。
这几乎让我想起了我们当时在 CSS 盒模型灾难中遇到的 22 条军规困境，以及这如何导致了整个 DOCTYPE 切换的想法，作为解决这个问题的最后努力……好吧，我们现在无法简单地用新的标记来解决这个问题。浏览器制造商和开发者都把自己逼到了一个死角。
对于那些提到“Firefox 没有改变以跟随 IE6”之类的人……实际上，早期的浏览器大战时期（尤其是 Netscape 消失之后）花费了大量时间来逆向工程 IE 使用的一些秘密技术，以获得更好的兼容性（主要是在 JavaScript 方面，必须承认，但也有一些未公开的 CSS 内容）。我一时想不起相关的资料，但如果需要，我可以做一些挖掘。
Chris：“我想知道有多少以 Firefox 为主要浏览器的人正在浏览因缺少 -moz- 前缀而损坏且无法使用的网站？我的猜测是：几乎没有。”
如果您查看大量面向移动设备的网站，尤其是在美国，它们几乎完全使用 -webkit 前缀（并且它们确实进行了疯狂的用户代理字符串嗅探等操作，这也没有帮助）。他们甚至没有考虑适当的编码实践和回退方案（简单的例子：一个框中的白色文本，然后他们使用一个供应商前缀定义一个深色渐变，但至少忘记为其他浏览器设置常规的深色背景颜色。最终结果：白色背景上的白色文本。真是太棒了……）
啊，但是开发者只是为市场份额最大的浏览器引擎编写代码，谁能责怪他们呢？好吧，根据这个理由，我们应该在 10 年前就坚持针对 Trident……
无论如何，这个抱怨已经太长了……
自从 Web 诞生以来，一路上出现了很多错误，我不会一一列举。我忍不住要引用温斯顿·丘吉尔的一句话。
成功就是能够从一个失败走向另一个失败，而不会失去热情。
这对供应商和设计师都适用。所以，是的，事情有点失控了，但同样，这都是关于犯错，对吧。如果浏览器需要保留供应商前缀，那就这样吧。我更喜欢有供应商前缀，它使这些东西现在成为可能，而不是在几年或几个月后。
我认为没有人谈论我认为其他供应商推动这样做主要原因是什么。
如果许多技术演示只能在 Webkit 上运行，并且许多网站在 Webkit 上看起来更好，那么用户将更愿意使用 Webkit，因为那里的一切都看起来更酷，运行得更好。这与网站是否完全崩溃无关，而是关于网络的总体体验更好，是的……在这方面，轻微的外观改进会产生巨大的差异，尽管每个人似乎都在说些什么。
现在其他浏览器正努力实现前沿的功能，但每个人都只使用 Webkit，并且为了保持竞争力，他们找到了一个非常简单的方法，他们自己主动地使自己的浏览器看起来处于领先地位，而不必让数万名 Web 开发人员来做这件事。
从供应商（供应商=出售某些东西的人）的角度来看，这最有意义，几乎是不言而喻的。
我同意这对整个网络来说是不利的，但让我们从供应商的角度来看待问题，以尝试找到解决方案。
“使他们的浏览器看起来处于领先地位”
啊……“看起来”？其他浏览器不会将前沿的 -webkit 内容映射到某种劣质的模拟，而是映射到完全相同的前沿功能。所以与看起来处于领先地位无关……它们处于完全相同的前沿（并且在许多领域，甚至比 -webkit 内容更进一步）。
有点道理，我无意暗示其他浏览器不如 Webkit。尽管如果它们没有这种感觉（即使实际上只是这样），为什么它们想要使用其他浏览器的前缀呢？
Damon：“使他们的浏览器看起来处于领先地位”
啊……“看起来”？其他浏览器不会将前沿的 -webkit 内容映射到某种劣质的模拟，而是映射到完全相同的前沿功能。所以与看起来处于领先地位无关……它们处于完全相同的前沿（并且在许多领域，甚至比 -webkit 内容更进一步）。
哎呀，抱歉重复发布。
Damon：这与其他浏览器感觉不如 Webkit 无关（啊？），而是为了弥补开发人员似乎甚至没有意识到他们如此勤奋地为 -webkit 添加前缀的功能实际上存在，并且在其他浏览器中也是以相同的方式存在的事实。其他浏览器正在解决开发人员的无知/懒惰（这里指的是诸如转换、2D 变换、圆角等非常常见的功能）。
对于开发者来说，这似乎成了一种自我实现的预言：他们只使用 -webkit 前缀的内容，然后他们分享自己对 Webkit 比其他浏览器更先进的印象……即使他们从未费心真正意识到这些完全相同的前沿功能也存在于其他浏览器中……
所以我真的不明白你的意思……
我曾经在 Twitter 上对 Patrick 说过这句话，但它值得重复……
“如果人们认为一家（提供美味食物的）餐厅实际上提供糟糕的食物，那么它最终无论如何都会倒闭。我们（我、Patrick、像我们这样的人）知道 IE6 过去的罪过正在 -webkit 中重演。但也许这对新手来说并不明显。”
这并不是说 WebKit 作为渲染引擎应该受到责备。
但是作为设计师，我们很快就会支持任何被认为处于（尽管这可能只是处于同一水平）前沿的浏览器。因为它使事情变得简单(些)，我们像对待 IE6 一样加冕一个国王——排斥其他浏览器。
因此，我们再次把自己逼到了一个死角，而不是继续本着 Web 标准——互操作性的精神来开发网站。（注意：是的，我知道我们现在讨论的是尚未标准化的 CSS）。
希望我没有显得过于教条。就我个人而言，如果必须做出这样的业务决策来排除旧浏览器，我也不会介意。但让我感到遗憾的是，由于设计师的无知和/或懒惰，功能完善的现代浏览器无法以其各自最佳的能力呈现页面。
再说一次，这并不是任何一个组织（或个人）的错。这仅仅是当前 Web 浏览器的现状。我一直试图尽可能地包含尽可能多的（当前版本）浏览器，因此，浏览器供应商之间甚至会对此进行讨论，这让我感到有些惊讶。
再说一次，我只是一个局外人（设计师），在观察。
我倾向于同意。
这是一个具有讽刺意味的情况。每个人都喜欢竞争，这样你就不会最终出现 IE6 式的统治和创新被扼杀的情况。
但与此同时，每个人都喜欢一个稳定、一致的设计平台……这使得单个浏览器/单个渲染引擎/单个（快速更新）标准库成为可能。
这里有三种类型的功能：标准、早期采用和实验。
我们应该……*试验*实验性功能，而不是将它们作为设计或应用程序的关键部分。不要因为用户没有选择我们的浏览器而惩罚他们。
但我们也不应该因为 Chrome 和 FireFox 决定成为早期采用者而受到惩罚。我的许多企业客户选择不成为早期采用者，因为他们遵循“标准”路线或“在所有浏览器中看起来都一样”的原则。
让我们保留实验性内容的前缀，但为早期采用提出另一种解决方案。也许添加 -x- 或 -w3c- 来表示它是一个广泛采用且预先批准的功能，或者让我们完全删除前缀。
Mozilla 的此举毫无意义，现在网络正在从 IE6 和遗留的杂乱无章中恢复过来，他们认为支持
-webkit-前缀是倒退的一步，对我来说，这就像我们再次使用表格进行布局一样。我一定是把头埋在沙子里，因为我完全没有意识到这种 Webkit 独有的编码。我只是确保定期查看 css3please 并相应地更新我的 CSS。毫不费力，毫不麻烦。
如果不是因为供应商前缀的困境，我可能就不会对 SASS 和 @mixins 感兴趣了——我喜欢柳暗花明。
@Lûhn 的德鲁伊——我以为我喜欢 -exp 的想法，除了跨浏览器的实现。
我喜欢乌龟
我完全赞成取消供应商前缀。我希望能看到一个适用于所有浏览器的“生产”和“实验”标签标准。*白日梦*