此前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