此前Tantek在W3CCSS工作小组的公开的会议上提过，Webkit-only移动网站的控制，造成了浏览器的垄断，Tantek陷入了当前的在Web标准领域的危机处境。Tantek讨论了Mozilla的解决方案——把Firefox移动封装成类似Webkit，并支持一些-webkit-CSS属性，这个举动给web标准社区带来了不小的轰动，特别是来自Opera和Microsoft的代表立即同意这个观点并宣布和Mozilla类似的计划。下面的讨论是通过EtherPad、即时通讯、e-mail和电话来整理的。
让我们从最基本的说起吧。Mozilla,Opera和Internet Explorer究竟有哪些计划？
我并不能代表Opera和InternetExplorer团队。Mozilla现在在针对一些有问题的行为分析移动网站。这些网站探测webkit的UA串，并对应地只传递高保真的移动网页内容，并且仅使用或主要使用-webkit-前缀的属性。
基于这些分析，我们在计划对Firefox移动版（FirefoxMobile）实现UA串，这个UA串能通过这个UA探测。讽刺的是，这样就好像启动Safari的时候Webkit添加”LikeGecko”到它的UA串——当符合收集到的数据时，实现基于一对一的特定的-webkit-前缀属性。
你们不会仅仅是广泛地把-webkit-改为-moz-对吧？这个计划，仅仅是支持一小部分的-webkit-属性？
是的。我们的目标是我们把我们需要支持的其它提供商前缀属性的数量最小化到通过数据调研过的那部分，这样，对于Firefox移动网页用户来说，意义是非常重大的。目前我们拥有的数据，并不包含所有的-webkit-属性。
另外，我们在考虑支持-webkit-前缀版本的属性，前提是我们同时支持这个属性的非前缀版本。这样，我们为网页开发者提供了基于标准的属性而不是使用带前缀的属性。
但是目前为止，我们还不知道哪些属性是被支持的，对吧？还是，已经公布了？
目前，我们还没有公布特定的属性列表。对于这点我们比较谨慎，对数据列表我们经过仔细的检查，以确保是通过数据调研所得到结果的——确保我们仅支持这个数据认为有理由的——确保效能，即是确保通过加上这样的支持，确实为Firefox的移动用户带来好处。
我假设这个列表会随时间而改变。这似乎会给开发者带来更多的困扰，因为-webkit-的某一部分被支持，但是另一部分不被支持。你是如何让开发者去了解哪个提供商支持哪个前缀的哪个属性？
提供商前缀属性从来都不是开发者去依赖的东西。这些属性曾经是，现在也是，用在测试阶段的，是CSS从草稿成为标准的过程中的一种技术。我希望开发者能及时学习非前缀的属性，并学习这些属性的实现。那些才是开发者需要依赖的。
但是，这样看起来并不理想。如果开发者坚持他们所依赖的东西—非前缀的属性—那么我们就不会处于这样的境地。
实际上，开发者坚持他们认为能依赖的东西，是我们处于这样境地的原因。一些带前缀的属性被认为能依赖和支持，这样并不助于推动标准的形成。
Mozilla会维护一套关于哪个前缀的哪个属性被支持到列表么？
Mozilla会继续编写文档，关于哪个前缀的哪个属性是Firefox支持的，在developer.mozilla.org上面。
好的，那么这就是你想要做的事情，但是你做这件事的原因呢？这个计划的目标是什么？
Mozilla的目标是开发webkit专有部分的网页，提供给其它的浏览器提供商，就像在几年前，面对IE专有的属性，Mozilla和Opera不得不行动一样。我们已经唤起了webkit移动网页垄断的问题，同时也唤起了竞争能力的不足的意识，尽管很多的从Mozilla、Opera和Microsoft来的宣讲者加入到编写标准的工作组团队中。
有这么多的人在努力宣讲这件事，为什么还是竞争能力不足呢？
在过去的十几年，网页标准的宣讲是非常有效率的，提高了关于有效的HTML+CSS、渐进增强、谦虚脚本、微格式等等的意识和应用。然而，撇开Mozilla的和其它宣讲者过去几年的努力不说，webkit专有的移动网页增长快到我们没法制止，特别是对照针对webkit的宣讲，我们的努力显得又低调又明显。
我们可以问个问题：哪里出了问题？我们怎样结束webkit移动网页的垄断，且不说至少有一些标准宣讲者在努力？这并不仅仅是一个原因。我认为有几个方面的因素，共同导致了这样的局面。
首先，webkit的创新有助于提高了尊重。
第二，webkit广泛应用于iPhone、Android和BlackBerry。这是个警告，即是，当很多的提供商只使用一种方法实现，就形成了一种垄断。
第三点，-webkit-特性已经被Apple和Google很好地宣传了，最主要的是在HTML5演讲稿和demo网站中。这些HTML5网站有些已经更新到用来实践CSS特性，使用了很多的提供商前缀（为了更好的跨浏览器的演示和编码）。然而，webkit-only版本的一些含义，至今还可以使用。
第四点，过去几年，在几乎多有的网页设计/网页开发的讲坛上的有很多的演讲，演讲者会很激情地讨论和演示***的***技术，展示使用-webkit-前缀属性所创建的网站和代码。这样，默默地鼓励了开发者编码大多数都是针对webkit的浏览器，或者说编码仅支持webkit浏览器，特别是在移动网站领域。
***，CSS工作组把这些创新的-webkit-前缀的属性形成标准以便让其它的浏览器来支持非前缀的属性，包括webkit浏览器本身，并提供给开发者一个他们可以依赖的基于标准的选择。CSS标准形成花费了太长时间，导致以上陈述的几点都已经恶化了。
你说你所做的是为了Firefox移动用户。所以这个计划只是应用在你的移动产品上，而不应用在桌面浏览器？
Firefox移动版本的UA串本来就和Firefox桌面版本的有差别，所以，是的，早前提到的那部分都是针对移动产品。至于实现特定的-webkit-属性，我们目前仅在移动设备支持它们。这样，可以限制它的膨胀，给网页开发者提供可依赖的一个Firefox/Gecko平台。
既然目标是提供一个一致的体验给移动用户，那很大可能你会决定逐步地提供一个一致的体验给Firefox的用户，不是吗？这样使得这个策略从移动扩展到桌面。
我们发现的问题，是针对webkit编写的移动网站。因为桌面版本有很多的浏览器种类，所以仅针对webkit编写的网站占比相对较少。这就是功能需求产生的原因——如果没有什么东西来帮助用户，那就不必要去实现。所以，虽然我们可以在Firefox的平台实现这个，但是如果这样做没能让用户得到更好的体验，那这样做的意义相对来说没那么大。然而，我们仍然要考虑这个对于开发者的影响，并且，那可能已经足够。我们可以尝试在测试阶段测试什么来得到反馈。
同样的道理，这看起来不像是局限于几个属性。倒更像是，既然已经开始，逐渐地，你会做到对待-webkit-就像你自己的前缀一样。或者，即使Mozilla不这样做，Opera和Microsoft也许会，然后，自然而然地，你也被迫这样做。你觉得是不是？
我觉得，那取决于我们能否打破webkit移动网页的垄断。历史证明，Mozilla和其它的提供商，成功打破了IE网页垄断，做法是通过实现有限的一些IE专有的特性，如innerHTML和XMLHttpRequest，这两个逐渐地成为了W3C的标准的一部分。Firefox并没有完全地实现IE特性。Mozilla对网页兼容性有细致可靠的跟踪记录和一对一编程实现的特性。
但是，假设，就像曾经一段时间内Opera把UA串默认指向IE的做法一样，如果Opera走在前面，并且广泛地支持-webkit-。那会不会迫使mozilla走上同样的道路呢？如果不会，那又是为什么？
如果其它的移动浏览器广泛地支持-webkit-，我不觉得会对现状有很大影响，因为主导的移动浏览器引擎，Webkit，已经广泛地支持了-webkit-前缀属性。
Peter-PaulKoch很坚定地说过，“不存在webkit”。很明显，你和他的想法完全不同。
Peter-PaulKoch提出的”不存在webkit”并不重要，重要的是网页开发者相信并且表现得就是”存在webkit”。于是他们通过webkit的UA串和仅使用-webkit-前缀的属性来编程和发布移动网站。否定它，并不代表它就不是。
开发者通过这样做，他们给非webkit（如Mozilla、Opera和Explorer）的用户一个弱化的体验或者更严重点，一个破碎的体验。是的，我们看到低水平的或者”手机特征的”功能弱化的体验都是从非webkit浏览器的移动网站来的。起码在一定程度上，你完全支持了他们所做的东西，除非他们有隐藏在-webkit-前缀背后的东西？
是的，当前版本的Firefox支持-moz-前缀的CSS3gradients，transforms和animations等。我们和CSS工作组在积极地努力，希望更快地增强各自的规范，并且对那些稳定的特性，则去掉提供商前缀。那样，我们可以帮助推动网页平台，是通过web标准而不是一大堆的提供商前缀。
一个网站崩溃的频率如何？如果网站很不同但是功能还可以，那大概就是我们对网页所期望的。看起来，你的实际弱点是你的网页渲染相对较差一些，而不是用户被抛弃。这是对使用非webkit浏览器的威胁吗？
网站并没有崩溃。这个低端手机网站不一样，并且相对地功能弱一些。当用户在同一个设备同一个网站的不同浏览器看到相对差的用户体验，他们抱怨的不是网站也不是设备，而是浏览器。
提供商前缀曾经约定，是可以公开测试实现过程，并且问题要在行为形成之前改正。这样渐变的语法获得了很大成功，例如，完全不兼容的语法被尝试使用，逐步地，统一的语法就出现了。这个计划似乎阻碍了这样的能力——即是，当提供商开始相互支持前缀，那么我们也能一起废弃前缀。这个结论有道理吗？
有时候人们对技术有些期望，觉得它会很***，没有任何的瑕疵。当然，这个期望没有任何的根据，所以，这是从何而来也不清楚了。CSS提供商前缀的道理一样。它们实际很成功了——很多浏览器几年来很愤怒地测试各种属性，然后逐渐地标准化。
特别是，Mozilla有个对于早期尝试-moz-前缀的很好的跟踪记录，当标准形成的时候，传送标准的非前缀的属性，同时废弃测试过的-moz-前缀的版本。这当中有时候会遇到挫折：比如，border-radius变成标准需要多长时间？这问题摆在大家面前。但是，webkit移动网页的垄断或许是***次让我们看清楚提供商前缀是有如此多的问题。撇开它们的虽不***但令人印象深刻的跟踪记录不说，我们现在是否应该放弃提供商前缀？
有些人呼吁说要使用通用的前缀取代提供商前缀，比如-x-或者-beta-。那你的看法如何？
其它标准形成过程的经验表明，当存在测试版的前缀如-x-，那么每个提供商除了支持非前缀的版本以外，确实到***都会支持这个-x-。比如，查看你的邮件的标题，你会看到很多的X-的头部。或者比如，对于PNG格式的图片，浏览器要支持image/png以外，还要支持image/x-png。
相反，对于CSS提供商前缀，Mozilla有可能去掉-moz-前缀的属性，把web向前推进。我相信，至少有其它的浏览器提供商已经能够在他们使用标准的非前缀的版本之后，逐步地废弃他们自己的提供商前缀属性。
为什么”全局的（universal）”的前缀不能像提供商前缀一样废弃？这两者有什么不同？
全局的前缀被认为是跨浏览器的可依赖的，然后，网络努力促使这个前缀的使用和支持变得更强壮——或许强壮到为兼容性而要求支持它们，就像刚刚提到的X-*邮件头部和内容类型。
当多种浏览器都支持-webkit-前缀的属性的时候，会有类似的风险。如果这些浏览器支持等同的非前缀的属性，并且我们鼓励网页开发者使用这些来推动标准前进，那么这个风险可以减缓一些，或者可以解决掉。然而，这并不会修复已有的针对webkit的移动网站。
所以，现在是专注于修复问题，冒着将来会创造同样问题的危险？那不就仅仅是延缓这个痛苦吗？
当然这是个很复杂的问题，因为有很多的变数和因素。修复历史问题同时又要确保将来的稳定性，这两者结合为帮助用户和开发者提供了一个很好的平衡。基于我们的策略，我们在研究和收集数据，并且期待扩展和重复。
没有哪个策略是没有风险的，但是什么也不做，或者假装没有问题存在，才是最有风险的事，因为那相当于让webkit移动网页垄断的现状更加的糟糕。过去曾经的网页垄断，导致开放的网页拖后了几年。
DanielGlazman，工作组（CSSWorkingGroup）的联合担任主席（co-chair），对你的计划提出了响应。我们该如何改善现状，你有什么建议吗？
做为网页开发者，有几件关键的事情要做。
首先，停止使用针对webkit的UA探测和内容服务，特别是在移动网页领域。
第二，停止使用-webkit-前缀属性，建议使用标准的非前缀的属性和稳定的属性，或者使用每一个提供商所支持的前缀属性。
第三，看到使用webkitUA探测的和仅使用-webkit-前缀属性的网站，帮助解释并修正。同样地，帮助解释并修正这样做的开发中的网站。
最重要的是，树立一个好榜样。首先和最重要地在你的网站、发表的文章、演讲当中使用网页标准。当讨论或做demo的时候或在编程的过程，不管在一个还是多个浏览器，都要警告自己，并且弄清楚了，今日的光鲜或许会毁了明天。
译文来自：The Vendor Prefix Predicament:ALA’s Eric MeyerInterviews Tantek Çelik
访谈双方分别是ERICMEYER和TANTEKÇELIK
