此前Tantek在W3CCSS工作小組的公開的會議上提過，Webkit-only移動網(wǎng)站的控制，造成了瀏覽器的壟斷，Tantek陷入了當(dāng)前的在Web標準領(lǐng)域的危機處境。Tantek討論了Mozilla的解決方案——把Firefox移動封裝成類似Webkit，并支持一些-webkit-CSS屬性，這個舉動給web標準社區(qū)帶來了不小的轟動，特別是來自O(shè)pera和Microsoft的代表立即同意這個觀點并宣布和Mozilla類似的計劃。下面的討論是通過EtherPad、即時通訊、e-mail和電話來整理的。

讓我們從最基本的說起吧。Mozilla,Opera和Internet Explorer究竟有哪些計劃？

我并不能代表Opera和InternetExplorer團隊。Mozilla現(xiàn)在在針對一些有問題的行為分析移動網(wǎng)站。這些網(wǎng)站探測webkit的UA串，并對應(yīng)地只傳遞高保真的移動網(wǎng)頁內(nèi)容，并且僅使用或主要使用-webkit-前綴的屬性。

基于這些分析，我們在計劃對Firefox移動版（FirefoxMobile）實現(xiàn)UA串，這個UA串能通過這個UA探測。諷刺的是，這樣就好像啟動Safari的時候Webkit添加”LikeGecko”到它的UA串——當(dāng)符合收集到的數(shù)據(jù)時，實現(xiàn)基于一對一的特定的-webkit-前綴屬性。

你們不會僅僅是廣泛地把-webkit-改為-moz-對吧？這個計劃，僅僅是支持一小部分的-webkit-屬性？

是的。我們的目標是我們把我們需要支持的其它提供商前綴屬性的數(shù)量最小化到通過數(shù)據(jù)調(diào)研過的那部分，這樣，對于Firefox移動網(wǎng)頁用戶來說，意義是非常重大的。目前我們擁有的數(shù)據(jù)，并不包含所有的-webkit-屬性。

另外，我們在考慮支持-webkit-前綴版本的屬性，前提是我們同時支持這個屬性的非前綴版本。這樣，我們?yōu)榫W(wǎng)頁開發(fā)者提供了基于標準的屬性而不是使用帶前綴的屬性。

但是目前為止，我們還不知道哪些屬性是被支持的，對吧？還是，已經(jīng)公布了？

目前，我們還沒有公布特定的屬性列表。對于這點我們比較謹慎，對數(shù)據(jù)列表我們經(jīng)過仔細的檢查，以確保是通過數(shù)據(jù)調(diào)研所得到結(jié)果的——確保我們僅支持這個數(shù)據(jù)認為有理由的——確保效能，即是確保通過加上這樣的支持，確實為Firefox的移動用戶帶來好處。

我假設(shè)這個列表會隨時間而改變。這似乎會給開發(fā)者帶來更多的困擾，因為-webkit-的某一部分被支持，但是另一部分不被支持。你是如何讓開發(fā)者去了解哪個提供商支持哪個前綴的哪個屬性？

提供商前綴屬性從來都不是開發(fā)者去依賴的東西。這些屬性曾經(jīng)是，現(xiàn)在也是，用在測試階段的，是CSS從草稿成為標準的過程中的一種技術(shù)。我希望開發(fā)者能及時學(xué)習(xí)非前綴的屬性，并學(xué)習(xí)這些屬性的實現(xiàn)。那些才是開發(fā)者需要依賴的。

但是，這樣看起來并不理想。如果開發(fā)者堅持他們所依賴的東西—非前綴的屬性—那么我們就不會處于這樣的境地。

實際上，開發(fā)者堅持他們認為能依賴的東西，是我們處于這樣境地的原因。一些帶前綴的屬性被認為能依賴和支持，這樣并不助于推動標準的形成。

Mozilla會維護一套關(guān)于哪個前綴的哪個屬性被支持到列表么？

Mozilla會繼續(xù)編寫文檔，關(guān)于哪個前綴的哪個屬性是Firefox支持的，在developer.mozilla.org上面。

好的，那么這就是你想要做的事情，但是你做這件事的原因呢？這個計劃的目標是什么？

Mozilla的目標是開發(fā)webkit專有部分的網(wǎng)頁，提供給其它的瀏覽器提供商，就像在幾年前，面對IE專有的屬性，Mozilla和Opera不得不行動一樣。我們已經(jīng)喚起了webkit移動網(wǎng)頁壟斷的問題，同時也喚起了競爭能力的不足的意識，盡管很多的從Mozilla、Opera和Microsoft來的宣講者加入到編寫標準的工作組團隊中。

有這么多的人在努力宣講這件事，為什么還是競爭能力不足呢？

在過去的十幾年，網(wǎng)頁標準的宣講是非常有效率的，提高了關(guān)于有效的HTML+CSS、漸進增強、謙虛腳本、微格式等等的意識和應(yīng)用。然而，撇開Mozilla的和其它宣講者過去幾年的努力不說，webkit專有的移動網(wǎng)頁增長快到我們沒法制止，特別是對照針對webkit的宣講，我們的努力顯得又低調(diào)又明顯。

我們可以問個問題：哪里出了問題？我們怎樣結(jié)束webkit移動網(wǎng)頁的壟斷，且不說至少有一些標準宣講者在努力？這并不僅僅是一個原因。我認為有幾個方面的因素，共同導(dǎo)致了這樣的局面。

首先，webkit的創(chuàng)新有助于提高了尊重。

第二，webkit廣泛應(yīng)用于iPhone、Android和BlackBerry。這是個警告，即是，當(dāng)很多的提供商只使用一種方法實現(xiàn)，就形成了一種壟斷。

第三點，-webkit-特性已經(jīng)被Apple和Google很好地宣傳了，最主要的是在HTML5演講稿和demo網(wǎng)站中。這些HTML5網(wǎng)站有些已經(jīng)更新到用來實踐CSS特性，使用了很多的提供商前綴（為了更好的跨瀏覽器的演示和編碼）。然而，webkit-only版本的一些含義，至今還可以使用。

第四點，過去幾年，在幾乎多有的網(wǎng)頁設(shè)計/網(wǎng)頁開發(fā)的講壇上的有很多的演講，演講者會很激情地討論和演示***的***技術(shù)，展示使用-webkit-前綴屬性所創(chuàng)建的網(wǎng)站和代碼。這樣，默默地鼓勵了開發(fā)者編碼大多數(shù)都是針對webkit的瀏覽器，或者說編碼僅支持webkit瀏覽器，特別是在移動網(wǎng)站領(lǐng)域。

***，CSS工作組把這些創(chuàng)新的-webkit-前綴的屬性形成標準以便讓其它的瀏覽器來支持非前綴的屬性，包括webkit瀏覽器本身，并提供給開發(fā)者一個他們可以依賴的基于標準的選擇。CSS標準形成花費了太長時間，導(dǎo)致以上陳述的幾點都已經(jīng)惡化了。

你說你所做的是為了Firefox移動用戶。所以這個計劃只是應(yīng)用在你的移動產(chǎn)品上，而不應(yīng)用在桌面瀏覽器？

Firefox移動版本的UA串本來就和Firefox桌面版本的有差別，所以，是的，早前提到的那部分都是針對移動產(chǎn)品。至于實現(xiàn)特定的-webkit-屬性，我們目前僅在移動設(shè)備支持它們。這樣，可以限制它的膨脹，給網(wǎng)頁開發(fā)者提供可依賴的一個Firefox/Gecko平臺。

既然目標是提供一個一致的體驗給移動用戶，那很大可能你會決定逐步地提供一個一致的體驗給Firefox的用戶，不是嗎？這樣使得這個策略從移動擴展到桌面。

我們發(fā)現(xiàn)的問題，是針對webkit編寫的移動網(wǎng)站。因為桌面版本有很多的瀏覽器種類，所以僅針對webkit編寫的網(wǎng)站占比相對較少。這就是功能需求產(chǎn)生的原因——如果沒有什么東西來幫助用戶，那就不必要去實現(xiàn)。所以，雖然我們可以在Firefox的平臺實現(xiàn)這個，但是如果這樣做沒能讓用戶得到更好的體驗，那這樣做的意義相對來說沒那么大。然而，我們?nèi)匀灰紤]這個對于開發(fā)者的影響，并且，那可能已經(jīng)足夠。我們可以嘗試在測試階段測試什么來得到反饋。

同樣的道理，這看起來不像是局限于幾個屬性。倒更像是，既然已經(jīng)開始，逐漸地，你會做到對待-webkit-就像你自己的前綴一樣?；蛘?，即使Mozilla不這樣做，Opera和Microsoft也許會，然后，自然而然地，你也被迫這樣做。你覺得是不是？

我覺得，那取決于我們能否打破webkit移動網(wǎng)頁的壟斷。歷史證明，Mozilla和其它的提供商，成功打破了IE網(wǎng)頁壟斷，做法是通過實現(xiàn)有限的一些IE專有的特性，如innerHTML和XMLHttpRequest，這兩個逐漸地成為了W3C的標準的一部分。Firefox并沒有完全地實現(xiàn)IE特性。Mozilla對網(wǎng)頁兼容性有細致可靠的跟蹤記錄和一對一編程實現(xiàn)的特性。

但是，假設(shè)，就像曾經(jīng)一段時間內(nèi)Opera把UA串默認指向IE的做法一樣，如果Opera走在前面，并且廣泛地支持-webkit-。那會不會迫使mozilla走上同樣的道路呢？如果不會，那又是為什么？

如果其它的移動瀏覽器廣泛地支持-webkit-，我不覺得會對現(xiàn)狀有很大影響，因為主導(dǎo)的移動瀏覽器引擎，Webkit，已經(jīng)廣泛地支持了-webkit-前綴屬性。

Peter-PaulKoch很堅定地說過，“不存在webkit”。很明顯，你和他的想法完全不同。

Peter-PaulKoch提出的”不存在webkit”并不重要，重要的是網(wǎng)頁開發(fā)者相信并且表現(xiàn)得就是”存在webkit”。于是他們通過webkit的UA串和僅使用-webkit-前綴的屬性來編程和發(fā)布移動網(wǎng)站。否定它，并不代表它就不是。

開發(fā)者通過這樣做，他們給非webkit（如Mozilla、Opera和Explorer）的用戶一個弱化的體驗或者更嚴重點，一個破碎的體驗。是的，我們看到低水平的或者”手機特征的”功能弱化的體驗都是從非webkit瀏覽器的移動網(wǎng)站來的。起碼在一定程度上，你完全支持了他們所做的東西，除非他們有隱藏在-webkit-前綴背后的東西？

是的，當(dāng)前版本的Firefox支持-moz-前綴的CSS3gradients，transforms和animations等。我們和CSS工作組在積極地努力，希望更快地增強各自的規(guī)范，并且對那些穩(wěn)定的特性，則去掉提供商前綴。那樣，我們可以幫助推動網(wǎng)頁平臺，是通過web標準而不是一大堆的提供商前綴。

一個網(wǎng)站崩潰的頻率如何？如果網(wǎng)站很不同但是功能還可以，那大概就是我們對網(wǎng)頁所期望的?？雌饋?，你的實際弱點是你的網(wǎng)頁渲染相對較差一些，而不是用戶被拋棄。這是對使用非webkit瀏覽器的威脅嗎？

網(wǎng)站并沒有崩潰。這個低端手機網(wǎng)站不一樣，并且相對地功能弱一些。當(dāng)用戶在同一個設(shè)備同一個網(wǎng)站的不同瀏覽器看到相對差的用戶體驗，他們抱怨的不是網(wǎng)站也不是設(shè)備，而是瀏覽器。

提供商前綴曾經(jīng)約定，是可以公開測試實現(xiàn)過程，并且問題要在行為形成之前改正。這樣漸變的語法獲得了很大成功，例如，完全不兼容的語法被嘗試使用，逐步地，統(tǒng)一的語法就出現(xiàn)了。這個計劃似乎阻礙了這樣的能力——即是，當(dāng)提供商開始相互支持前綴，那么我們也能一起廢棄前綴。這個結(jié)論有道理嗎？

有時候人們對技術(shù)有些期望，覺得它會很***，沒有任何的瑕疵。當(dāng)然，這個期望沒有任何的根據(jù)，所以，這是從何而來也不清楚了。CSS提供商前綴的道理一樣。它們實際很成功了——很多瀏覽器幾年來很憤怒地測試各種屬性，然后逐漸地標準化。

特別是，Mozilla有個對于早期嘗試-moz-前綴的很好的跟蹤記錄，當(dāng)標準形成的時候，傳送標準的非前綴的屬性，同時廢棄測試過的-moz-前綴的版本。這當(dāng)中有時候會遇到挫折：比如，border-radius變成標準需要多長時間？這問題擺在大家面前。但是，webkit移動網(wǎng)頁的壟斷或許是***次讓我們看清楚提供商前綴是有如此多的問題。撇開它們的雖不***但令人印象深刻的跟蹤記錄不說，我們現(xiàn)在是否應(yīng)該放棄提供商前綴？

有些人呼吁說要使用通用的前綴取代提供商前綴，比如-x-或者-beta-。那你的看法如何？

其它標準形成過程的經(jīng)驗表明，當(dāng)存在測試版的前綴如-x-，那么每個提供商除了支持非前綴的版本以外，確實到***都會支持這個-x-。比如，查看你的郵件的標題，你會看到很多的X-的頭部?；蛘弑热纾瑢τ赑NG格式的圖片，瀏覽器要支持image/png以外，還要支持image/x-png。

相反，對于CSS提供商前綴，Mozilla有可能去掉-moz-前綴的屬性，把web向前推進。我相信，至少有其它的瀏覽器提供商已經(jīng)能夠在他們使用標準的非前綴的版本之后，逐步地廢棄他們自己的提供商前綴屬性。

為什么”全局的（universal）”的前綴不能像提供商前綴一樣廢棄？這兩者有什么不同？

全局的前綴被認為是跨瀏覽器的可依賴的，然后，網(wǎng)絡(luò)努力促使這個前綴的使用和支持變得更強壯——或許強壯到為兼容性而要求支持它們，就像剛剛提到的X-*郵件頭部和內(nèi)容類型。

當(dāng)多種瀏覽器都支持-webkit-前綴的屬性的時候，會有類似的風(fēng)險。如果這些瀏覽器支持等同的非前綴的屬性，并且我們鼓勵網(wǎng)頁開發(fā)者使用這些來推動標準前進，那么這個風(fēng)險可以減緩一些，或者可以解決掉。然而，這并不會修復(fù)已有的針對webkit的移動網(wǎng)站。

所以，現(xiàn)在是專注于修復(fù)問題，冒著將來會創(chuàng)造同樣問題的危險？那不就僅僅是延緩這個痛苦嗎？

當(dāng)然這是個很復(fù)雜的問題，因為有很多的變數(shù)和因素。修復(fù)歷史問題同時又要確保將來的穩(wěn)定性，這兩者結(jié)合為幫助用戶和開發(fā)者提供了一個很好的平衡?；谖覀兊牟呗?，我們在研究和收集數(shù)據(jù)，并且期待擴展和重復(fù)。

沒有哪個策略是沒有風(fēng)險的，但是什么也不做，或者假裝沒有問題存在，才是最有風(fēng)險的事，因為那相當(dāng)于讓webkit移動網(wǎng)頁壟斷的現(xiàn)狀更加的糟糕。過去曾經(jīng)的網(wǎng)頁壟斷，導(dǎo)致開放的網(wǎng)頁拖后了幾年。

DanielGlazman，工作組（CSSWorkingGroup）的聯(lián)合擔(dān)任主席（co-chair），對你的計劃提出了響應(yīng)。我們該如何改善現(xiàn)狀，你有什么建議嗎？

做為網(wǎng)頁開發(fā)者，有幾件關(guān)鍵的事情要做。

首先，停止使用針對webkit的UA探測和內(nèi)容服務(wù)，特別是在移動網(wǎng)頁領(lǐng)域。

第二，停止使用-webkit-前綴屬性，建議使用標準的非前綴的屬性和穩(wěn)定的屬性，或者使用每一個提供商所支持的前綴屬性。

第三，看到使用webkitUA探測的和僅使用-webkit-前綴屬性的網(wǎng)站，幫助解釋并修正。同樣地，幫助解釋并修正這樣做的開發(fā)中的網(wǎng)站。

最重要的是，樹立一個好榜樣。首先和最重要地在你的網(wǎng)站、發(fā)表的文章、演講當(dāng)中使用網(wǎng)頁標準。當(dāng)討論或做demo的時候或在編程的過程，不管在一個還是多個瀏覽器，都要警告自己，并且弄清楚了，今日的光鮮或許會毀了明天。

譯文來自：The Vendor Prefix Predicament:ALA’s Eric MeyerInterviews Tantek Çelik

訪談雙方分別是ERICMEYER和TANTEKÇELIK