公認的擁有一個編寫和管理CSS的方法比什麼都要更好。盡管如此，一些開發人員的實踐是不利於語義化質量和長期的可維護性。我們要討論一些被提倡的"CSS框架方法”的問題和作為web開發人員，我們如何可以更好的解決這些問題。
今天最流行的CSS開發框架技術當屬OOCSS，盡管還有其他類似的技術存在，如BEM。這些方法試圖對CSS采用面向對象的編程原則。盡管樣式語言和面向對象的軟件設計原則在概念之間存在一定的問題，這些微妙的東西對於一個欠缺經驗的開發人員來說可能不會立即顯現出來。最令人不安的是，這些方法已經可以廣泛的看到博客給其冠以"最佳實踐"的評價。“abscence”的證據來闡述使用這些方法的好處——選擇高流量網站只是一小部分——這反應了我的觀點，他們代表了一種誤導和盲目的崇拜。
在計算機科學中只有兩硬東西：緩存失效和命名的事情——Phil Karlton
Web從根本上來產一個語義媒介。這是一個至關重要的功能平台，通過一個巨大的一系列不同類型的技術打算向許多不同的語言、文化、性別、年齡、生理和認識能力的人們呈現。看起來沒有單一的視覺Web，除非你正在構建的東西明確知道了他們的范圍很狹窄，因此語義的方法作為一個網頁開發商應該成為你所做事情的一切核心。
當編寫Html，有三種主要的方式表達內容、Web界面或應用程序的語義化：內容使用的元素類型制作的模板；使用ID用來識別一個獨特的，單個元素；用類名來分類一組元素。
這三種之中，用於綁定介紹HTML文檔是最常用的工具。重要的是要注意，討論類的名稱時，W3C最近的候選人推薦Html5的時候說：
沒有額外的限制情況之下，作者可以使用類的屬性，但鼓勵作者使用類的屬性值描述內容的性質，而不是只描述內容所需要的表現形式——更多。
在規范中沒有明確的規定類的屬性目的是服務什麼，但建議用其來描述內容的語義。盡管如此，它已經變得非常常見，web開發人員錯誤地引用來的屬性為"CSS類"或者類似的。正如Tantek Çelik的筆記描述的：
能過使用短語“CSS類”或“CSS類名稱”，你不僅是不精確的（或者完全錯誤），你將使用上下文/框架的表像與“CSS”類的名字所暗示的那樣捆綁在一起，甚至鼓勵實踐表表象的類名，這是一種壞的實踐方式——Tantek Çelik。
這樣的建議完全不符合框架方法，他們選擇忽視它。因為類名稱在項目類型中必須描述他們的介紹，這樣才具有語義——盡管有反對的聲音。但為什麼要語義化的類名，他們重要嗎？在最基本的層面上它是維護與平台無關的東西，甚至包括設計的原理，正如Tim Berners Lee在網絡的普遍性中所描述的一樣。但也因為我們無法預測不來的創新技術可以用於今天的創建。
快速測試你的Html有沒有語法化：你可以使用它作為一個公共的API嗎？——Alex Gaynor(@alex_gaynor)
Microformats是一個例子。唯一的原因就是這些文檔作者使用了語義化類名來描述常見的結構，如地址和約會的日歷。通過篡改某些用於描述數據約定的這種方式，標記不僅讓你的網站訪客就得有用，軟件也懂得和使用他在全新和無法想像的方式中。Microformats演示了語義化類名的有用性，可是令人失望的看到它們被解散：
類名傳授少或沒有有用的語義化信息的機器或訪客，除非它是商定中的一小部分（和機器可讀的）名字，Microformats。——Nicolas Gallagher
“小套約定的名稱”和所有潛在的，未來使用的內容和今天發布的之間的區別，純粹是由CSS框架思想給驅動的。口述那些無語義化的類名，結構和文檔內容，雖內容被呈現了，但這樣明顯違背了關注的原則。
創建網站的時候，我們必須確保我們的產品是有遠見的，足以輕松維護和升級產品。現代的網站和應用程序越來越多的工作是大批大批的前端人員在開發。在這種環境下，什麼什麼方法可以成功的貫穿作者所在的CSS團隊是非常重要的，因為其中一些人可能只在產品的壽命期的階段工作，或者他們可能沒有在產品的開發期中工作過。在這個環境中，許多挑戰和實現CSS就出來了，如：
也許最重要的是讓前端開發人員通過一個CSS框架技術來解決一個網站中重復的CSS代碼是首要的事情。通過類，類名派生選擇器，一個開發人員可以增加選擇器的有用性，並在不同的元素中使用相同的樣式規則。考慮下面的類的示例，它使任何匹配的元素具有一致的邊框、內距和排版風格：
開發人員可能會將這個類定義在任意數量的元素之上，這些元素將都具有這種樣式風格。有可能其他元素不使用所有的風格，而是需要覆蓋特定的樣式，他們需要添加另一個類名，並在CSS源文件下面加上樣式代碼。作為兩個類具有相同的權重，後者聲明的樣式將優秀考慮：
通過這種方式在模板中添加兩個類名用來減少重復的代碼是可取的，同時這兩個類名也傳達了特定的語義。
這裡開發人員真正需要一個“混合”和"擴展",這些在各種CSS預處理器中都有，比如LESS或者Sass。一組相關的屬性可以被分組為一個mixin或者@extend placeholder，然後可以給一個完全表像的名字：它們本身在任何地方都不會生成代碼(除非你想要用它，或者說你調用他們)，所以任何CSS選擇器都可以調用他們的規則。這裡有一個關於mixin在SCSS語法中的簡單示例：
改變mixin的樣式風格總是通過div.breaking來實現，並且盡可能的與模板不耦合在一起。在CSS中能夠定義mixin就是他一直以來想要的特性(這功能最終在預處理器中實現。)，如果你想成為一個專業的CSS開發人員，你沒有什麼好理由不使用CSS預處理程序。
如果你從未接觸過CSS預處理程序，不仿先點擊《Sass教程》，了解有關於CSS預處理程序之一的Sass使用——@大漠。
維護項目對於解耦或者關注分離是非常重要的；模板和CSS耦合過於密集，維護的成本將會增加。早期有效的CSS都是通過所見即所得的網頁開發工具比如Dreamweaver,FrontPage生成，導致很多網站的代碼，看上去很像這樣：
這種基於模板基礎上的內聯樣式只能適可而止，這些標簽組合在90年代末直接影響Web的發展。當設計需要修改，所有這些內聯樣式都需要跟蹤並替換。很多開發人員的修改讓我感到很悲哀，可以這些天的教訓都給忘了，我們仍然可以看到像這樣的修改代碼：
這例子可能有點太極端了，但它的邏輯來自於CSS框架中，拋棄語義化類名和選擇器，在一味的追求“模塊化”。這樣避免在CSS中有重復的代碼，不過轉移到模板中，導致的副作用就是模板和樣式的緊耦合性。
另一個目標是提供高性能。這取決天很多因素，如客戶端訪問一個網頁的類型，他們的連接速度和內容是否有被緩存，還有其他一些因素等等。在最基本的級別上有三種東西最明顯的影響CSS性能：
前兩個考慮的范圍可以采用CSS框架方法，而第三個是通過類名來解決重用：其目的是，通過聲明盡可能少的樣式越少，CSS文件就越可能的小。
提供這樣的一個CSS文件可能是被誤導的，然而通過使用短選擇器和更少的樣式規則，和把更多的類綁定到標記中（更多長類名），被轉移的數據量並不一定會下降—，但它確實從CSS文件中移出更多的東西。
引用CSS框架方法保持CSS選擇器短小，是具有性能優勢。這在現代浏覽器引擎中已經證明是有效率，但在極端的邊緣情況之下，速度的增長依靠重寫你的選擇器是可以忽略不計的。同時前端性能追求的是：
許多人似乎沒有意識到（或不談），性能往往是存在的，而且具有成本的，它會花費很多維護成本。——NIEls MatthiJS
當重溫舊代碼或者當一個新的成員加入一個項目CSS框架方法暴露出一些嚴重的問題。主要是提供的這些方法幾乎沒有發現。Nicolas Gallagher在他寫的前端架構文章中說“類名應該給開發傳達有用的信息”。我想加強一下：“選擇器應該是和開發者交流的有用信息”。目的是相同的——讓我理解在哪使用這些規則——但一個選擇器給開發人員傳遞更有用信息，因為它傳達了上下文。這樣更容易理解，選擇器告訴你，它只適用於在一定范圍內的元素。一個社會成員列表的鏈接可以考慮兩種樣式：
或者
後者更容易讓那些不熟悉代碼庫的人理解。它也是更容易被發現：一個新的開發人員如果無法或沒有閱讀整個CSS代碼庫，是沒辦法知道哪個規則是合適的。
優秀的代碼不僅是正確的，也應該是容易閱讀的。它不只是計算機通信的一種算法，還要能讓人可以讀取它。通過尋找我們代碼中的優秀部分，我們建立更好的代碼。學習編寫代碼一個首要條件是讓代碼易讀，進一步才是學習如何編寫優秀的代碼和照顧和幫助使用代碼的人如何更好的使用。優秀的代碼都是易讀和易用的。——Eric S.Raymond。
可以發現一些問題，框架方法讓代碼變得臃腫。通過編寫特定的選擇器，同時為了讓開發人員得到必要的信息，致使文檔變得龐大。例如上面的例子，如果社會成員列表從網站中刪除，整個CSS塊也可以刪除，而靈活的類名選擇器可能還用於網站其他的地方，無法確保刪除不會引起別的問題出現。
Matt Wilcox對於性能做出如下的闡述：
性能是一個浏覽器水平問題，它不應該由作者圍繞HTML/CSS做修復或解決。只要我們編寫有效的和可用的HTML/CSS，並不要為了提高頁面渲染速度而遵循這些可笑的規則。這些東西版本更新越來越快。使用JS的人需要擔心自己的代碼影響性能。如果你想充分利用你的Html/CSS，需要考慮的是最佳實踐，而不是性能問題。可憐的性能將在新版的浏覽器發布得到一定的修復，但劣質的代碼並不會隨著新版浏覽器發布而改善。——Matt Wilcox
前端開發人員多年來一直悄悄地和世功構建大型的Web項目，而並沒有使用CSS框架方法。事實上，這些項目已設法避免使用OOCSS，BEM和其他人所說的有效的工作方式。這裡有一些我與別認討論編寫CSS的建議和我自身的經驗。
很多CSS框架方法建議使用ID是一個錯誤的想法。這背後的原因是，ID具有較高的權重，使其他地方覆蓋需要使用!important規則。我強烈不同意：Angus Croll這樣描述的：“回避策略一直讓我感到困擾，直到你知道從裡面走出來，因為你不能掌握一門語言——恐懼和逃避是知識的最大敵人”。如果你是一個專業的web開發人員，您應該了解權重的工作方式，以及它如何影響你寫的選擇器。更重要的是，ID是一個有效的文檔結構的一部分和具有非常強大的功能和語義。
如果你正在編寫CSS，目標可以出現在文檔中的任何一個元素，使用選擇器反映了這一點。如果使用CSS只是在非常特殊的情況之下，那麼這將違反了使用選擇器原則。首先，不要讓你的選擇如此簡潔，半年下來會讓你的項目變得面目全非。
害怕寫CSS是過於具體，實際上是過早的優化。編寫CSS是你需要做的工作，當他要被重用，你應該適當的將它制作成一個mixin。也許下周修改的時候，整個功能將被丟掉。你不會想要生成一堆冗余類選擇器，沒有人理解你的目的，或者避免移除的風險。
你是專業的web開發人員。你不需要寫在記事本中，所以不要限制自己使用最好的工具來幫你做你想做的事情。你正在用什麼框架或平台上開發並沒有太大的關系，CSS預處理程序工具可以幫你。也有很多優秀的例子，如何有效的跨項目重用CSS。讀起來，看看它是如何被其他地方重用，可以拓寬你的知識面。
網站和應用程序總有一些習慣類型，如標簽和輸入框，列表鏈接放在<nav>元素裡，一系列的標簽和值等等。當接近任何給定的特性，首先使用靜態的Html構建適應的模板。這不僅可以作為一個測試用例，也可以確保之使用使用不會用錯，同時也幫助新進團隊成員可以看到，不至於被代碼整暈。這些頁面的截圖或應用程序本身，不管是手動還是通過一個自動化的工具持續將這些東西集成在一起，可以用來檢測代碼是否遭到破壞。
在復雜的Web應用程序設計一個好的CSS架構是很困難的(這就是為什麼優秀的前端開發人員都有這樣的需求)，但我們不應該對於新手任意強加這些對於自己都有難度的規則，這樣只會導致不必要的復雜性和增加維護的成本。
通過對自己產品的理解與構建，你會更好的決定如何為產品創建結構的方方面面，不僅僅它是如何呈現。網絡是一個語義媒介：讓它成為你的向導。
It is the pervading law of all things organic and inorganic, of all things physical and metaphysical, of all things human and all things superhuman, of all true manifestations of the head, of the heart, of the soul, that the life is recognizable in its expression, that form ever follows function. This is the law.——Louis Sullivan
在寫這篇文章在Mark Norman Francis、Brad Wright、Ross Bruniges、Jake Archibald和Patrick Griffiths的反饋中得到極大的幫助。
譯者手語：整個翻譯依照原文線路進行，並在翻譯過程略加了個人對技術的理解。如果翻譯有不對之處，還煩請同行朋友指點。謝謝！
如需轉載，煩請注明出處：
英文原文：http://www.kapowaz.Net/articles/cargo-cult-CSS
中文譯文：http://www.w3cplus.com/css/cargo-cult-CSS.Html