以下內容摘自《CSS揭秘》一書　

　在標準的開發過程中，總是有大大的"第22 條軍規"1①擋在面前：標準的工作組需要網頁開發者這一端的輸入，以確保各項規範可以處理真實的開發需求；但是開發者往往沒有興趣嘗試那些在生產環境中還不能使用的東西。當實驗性的技術被廣泛應用到生產時，工作組就被這些技術早期的、實驗性的版本捆住手腳了，因為一旦這些技術有變動，那些已經在用這些技術的網站就掛了。顯然，這完全否定了讓開發者嘗試早期標準的好處。

　　這些年來，為了解決這個難題，許多方案被提了出來，但都不夠完美。飽受詬病的瀏覽器前綴就是其中之一。這個方案是指每個瀏覽器都可以實現這些實驗性的（甚至是私有的、非標準的）特性，但要在名稱前面加上自己特有的前綴。最常見的前綴分別是Firefox 的-moz-、IE 的-ms-、Opera 的-o- 以及Safari 和Chrome 的-webkit-。網頁開發者可以自由地嘗試這些加了前綴的特性，並把試用結果反饋給工作組，而工作組隨後會將這些反饋吸收到規範之中，並且逐漸完善該項特性的設計。由於最終標準化的版本會有一個不同的名稱（沒有前綴），它在實際應用中就不會跟加前綴版本相沖突了。

　　聽起來不錯，對吧？但是你可能也猜到了，現實與我們的期望往往有很大的落差。當開發者發現這些實驗性的、加了前綴的屬性可以輕而易舉地實現以前大費周章才能達到的效果時，他們就開始濫用了。這些加了瀏覽器前綴的屬性迅速成為CSS 領域的一大潮流。網上的教程會寫到它們，Stack Overflow 上的問答會提到它們……很快，幾乎每個有上進心的CSS 開發者都開始爭先恐後地使用它們。

　　不久，網頁開發者們就發現，在使用這些神奇的新特性時，如果只寫出當下有效的瀏覽器前綴，就意味著以後要經常回來打補丁：每當又一個瀏覽器實現了這個新特性時，他們都需要多加一行。跟進各個特性在各個瀏覽器下是不是要加前綴，光是想想就讓人頭皮發麻。開發者會怎樣應對？那就是先發制人地加上所有可能的瀏覽器前綴，再把無前綴的版本放在最後，以圖一勞永逸。我們最終寫出的代碼可能就是這樣的：

-moz-border-radius: 10px;  
-ms-border-radius: 10px;  
-o-border-radius: 10px;  
-webkit-border-radius: 10px;  
border-radius: 10px; 

　　這裏面有兩條聲明是完全多余的：-ms-border-radius 和-o-border-radius 這兩個屬性從來沒有在任何瀏覽器中出現過，因為IE 和Opera 從一開始就是直接實現border-radius 這個無前綴版本的。

　　顯然，把每個聲明都重復五遍是相當枯燥的，而且很難維護。因此出現某個工具來把這項工作自動化只是個時間問題。

　　■ 像CSS3, Please!（http://css3please.com）和pleeease（http://pleee-ase.io/playground.html）這樣的網站允許你把無前綴的CSS 代碼粘貼進去，它們會自動幫你把必要的前綴都加好。這類網站是"前綴危機"所催生出的第一批工具，很快就過氣了，因為跟其他方案相比， 它們的使用成本太高了。

　　■ Autoprefixer（https://github.com/ai/autoprefixer）采用Can I Use... （http://caniuse.com）的數據庫來判斷哪些前綴是需要添加的；此外， 它是在本地完成編譯的，類似預處理器。

　　■ 我自己開發的 -prefix-free（http://leaverou.github.io/prefixfree）會在瀏覽器中進行特性檢測，來決定哪些前綴是需要的。它的好處在於幾乎不需要更新，因為其所有信息都是用一份屬性清單在真實的瀏覽器環境中跑出來的結果。

　　■ 類似Stylus（http://stylus-lang.com/）、LESS（http://lesscss.org） 或Sass（http://sass-lang.com）的預處理器並不自帶任何加前綴的方法， 但很多人開發過一些能為常用屬性加前綴的mixin；社區中也有一些庫提供了這類mixin。

　　由於網頁開發者使用無前綴的屬性是想確保代碼的向前兼容，那麽工作組想要修改這些無前綴語法就變得不可能了。我們基本上就跟這些半生不熟的早期規範綁在一起了，只能通過極其有限的途徑來修改它們。用不了多久，這個"坑"裏的每個人就會意識到，瀏覽器前綴已是一場史詩般的失敗。

　　最近，瀏覽器廠商已經很少以前綴的方式來實驗性地實現新特性了。取而代之的是，這些實驗性特性需要通過配置開關來啟用，這可以有效防止開發者在生產環境中使用它們，因為你不能要求用戶為了正確地瀏覽你的網站而去修改瀏覽器設置。當然，這會導致一個後果：嘗試這些實驗性特性的開發者會減少；但我們仍然會得到足夠多的反饋，甚至是更高質量的反饋（你可能會質疑），同時還避免了瀏覽器前綴的所有缺點。不過我們還需要很長的時間，才能從瀏覽器前綴所引發的漣漪效應中解脫出來。

冰與火之歌：瀏覽器前綴