CSS架構目標：預測、重用、擴充、維護

擅長CSS的Web開發人員不僅可以從視覺上複製實物原型，還可以用代碼進行完美的呈現。無需使用表格、儘可能少的使用圖片。如果你是個名副其實的高手，你可以快速把最新和最偉大的技術應用到你的項目中，比如媒體查詢、過渡、濾鏡、轉換等。雖然這些都是一個真正的CSS高手所具備的，但CSS很少被人單獨拿出來討論，或者用它去評估某個人的技能。

有趣的是，我們很少這樣去評價其他語言。Rails開發人員並不會因為其代碼比較規範，就認為他是一名優秀的開發人員。這僅僅是個基準。當然，他的代碼得必須規範。另外，還需集合其他方面考慮，比如代碼是否可讀？是否容易修改或擴充……

這都是些很自然的問題，CSS和它們並沒有什麼不同之處。今天的Web應用程式要比以往更加龐大。一個缺乏深思熟慮的CSS架構往往會削弱發展，是時候像評估其他語言那樣，來評估一下CSS架構了，這些都不應該放在“事後”考慮或者單單屬於設計師們的事情。

1.良好的CSS架構目標

在CSS社區，很難提出某個最佳實務已經成為大家的普遍共識。純粹地從Hacker News的評論上判斷和開發人員們對CSS Lint發布後的反應來看，大多數人對基本的CSS東西是持反對意見的。所以，並不是為自己的最佳實務奠定一套基本的論據，而應該確定真正的目標。

好的CSS架構目標並不同於開發一個好的應用程式，它必須是可預測、可重用、可維護和可伸縮的。

可預測

可預測意味著可以像預期的那樣規範自己的行為。當你添加或者修改某個規則時，它並不會影響到沒有指定的部分。對於一個小網站來說，一些微乎其微的改變並不算什麼。而對於擁有成千上萬個頁面的大網站來說，可預測卻是必須的。

可重用

CSS規則應具備抽象和解耦性，這樣你就可以在現有的基礎上快速構建新的組件，無需重新修改編碼模式。

可維護

當把新組件放置到網站上，並且執行添加、修改或者重新設計操作時，無需重構現有CSS，並且新添加的X並不會打破原有頁面的Y組件。

可擴充

當網站發展到一定規模後，都需要進行維護和擴充。可擴充的CSS意味著網站的CSS架構可以由個人或者團隊輕易地管理，無需花費太多的學習成本。

2.常見的錯誤實踐

在實現良好的CSS架構目標之前，我們來看一些常見的錯誤做法，這對我們達成目標是有好處的。

下面的這些例子雖然都可以很好的執行，但卻會給你帶來很多煩惱，儘管我們的意圖和願望都是美好的，但是這些開發模式會讓你頭疼。

幾乎在每個網站上，都會有一個特定的虛擬元素看起來與其他頁面是完全一樣的，然而只有一個頁面除外。當面對這樣一種情況時，幾乎每個新手CSS開發人員（甚至是經驗豐富的）都會以同樣的方式來修改。你應該為該頁面找出些與眾不同之處（或者自己建立），然後再寫一個新規則去操作。

基於父組件來修改組件

1. .widget {  
2.   background: yellow;  
3.   border: 1px solid black;  
4.   color: black;  
5.   width: 50%;  
6. }  
7.  
8. #sidebar .widget {  
9.   width: 200px;  
10. }  
11.  
12. body.homepage .widget {  
13.   background: white;  
14. } 

初看，這絕對是段無害的代碼，但讓我們來看看它是否達到了我們所設定的目標。

首先，widget在examle是不可預見的。當這些小組件出現在頁面兩側或者首頁面時，開發人員期望它們以某種特定的方式顯示出來，且又不失特色。另外，它也是不可重用或不可擴充的。

另外，它也比較難維護。一旦這個widget需要重新設計，那麼你不得不修改其他幾個CSS樣式。想象一下，如果這段代碼是使用其他語言編寫的，它基本就是一個類定義，然後在代碼的另一部分使用該類定義並做出擴充。這直接違反了軟體開發的開放/閉合（open/close）原則。

軟體實體（類，模組，函數等）應對擴充開放，對修改閉合。

過於複雜的選取器

偶爾，會有些文章介紹CSS選取器對整個網站的展示起著非常重要的作用，並且宣稱無需使用任何類別選取器或者ID選取器。

但伴隨著越深入的開發，我越會遠離這種複雜的選取器。一個選取器越複雜，與HTML就越耦合。依靠HTML標籤和組合器可以保持HTML代碼乾乾淨淨，但卻讓CSS更加毛重和淩亂。

1. #main-nav ul li ul li div { }  
2. #content article h1:first-child { }  
3. #sidebar > div > h3 + p { } 

對上面代碼進行簡單的理解。第一個可能是對下拉式功能表進行樣式化；第二個想說明文章的主標題應該與其他頁面的H1元素不同；最後一個表示在第一段的側邊欄地區添加一些額外的空間。

如果這個HTML是永遠不變的，那就無可說之處，但這根本毫不現實。過於複雜的選取器會讓人印象深刻，它可以讓HTML擺脫掉表面上的複雜，但對於實現良好的CSS架構目標卻毫無用處。

上面提到的例子都是不具備可預測性、可重用、可擴充和可維護這四大特性的。例如第一個選取器（下來菜單）例子，如果一個外觀非常相似的下拉式清單需要用在不同的頁面上，並且#main-nav並不屬於內部元素，那麼你是否需要重新設計？假設開發人員想要修改第三個例子裡div裡面部分標記，那麼整個規則都會被打破。

過於通用的類名

當建立可重用的設計組件時，在組件的類別選取器中覆蓋附件的子項目是很常見的現象。例如：

1. <div class="widget">  
2.   <h3 class="title">...</h3>  
3.   <div class="contents">  
4.     Lorem ipsum dolor sit amet, consectetur adipiscing elit.  
5.     In condimentum justo et est dapibus sit amet euismod ligula ornare.  
6.     Vivamus elementum accumsan dignissim.  
7.     <button class="action">Click Me!</button>  
8.   </div>  
9. </div> 

1. .widget {}  
2. .widget .title {}  
3. .widget .contents {}  
4. .widget .action {} 

像.title、.contents、.action這些子項目類別選取器可以被安全地進行樣式命名，無需擔心這些樣式會蔓延到擁有相同類名的其他元素中。這是千真萬確的。但它並沒有阻止相同樣式類名稱會蔓延到這個組件上。

在一些大型項目上，像.title這樣的名稱很有可能會被用在另外一個頁面或者本身。如果這樣的情況發生，那麼整個標題部分明顯會和預期的不一樣。

過於通用的類別選取器名稱會導致許多不可預測的CSS樣式發生。

一個規則做太多事

有時，你要在網站的左上方地區做一個20pixels的可視化組件。

1. .widget {  
2.   position: absolute;  
3.   top: 20px;  
4.   left: 20px;  
5.   background-color: red;  
6.   font-size: 1.5em;  
7.   text-transform: uppercase;  
8. } 

下面，你需要在網站的其他地區使用該組件，那麼上面的這個代碼明顯是錯誤的，不可重用的。

問題的關鍵是你讓.widget這個選取器做的事情太多，不僅對該組件的位置進行了規定，還對它的外觀和感覺方面進行了樣式。外觀和感覺可以通用，而位置是不可以的。有時候，把它們整合起來使用反而會大打折扣。

雖然這些看起來並無害處，對一些缺乏經驗的CSS程式員來說，複製和粘貼已經成為一種習慣。如果一個新團隊需要一個特定組件，比如.infobox，他們會嘗試使用這個類別選取器。但如果該資訊框沒有按照期望的那樣，在每個需要的地方正確顯示出來。這時，你認為他們會怎麼做？以我的經驗來看，他們會打破可重用這一規則，相反，他們會簡單地把這些代碼複製粘貼到每個需要的地方。做些不必要的重複工作。

3.原因

上面列舉的這些常規錯誤實踐都有一個相似性，CSS樣式承擔過多。

對這樣的說法你會感到奇怪，畢竟，它是一個樣式表，難道不應該承擔大多數（如果不是全部）的樣式嗎？那不正是我們想要的嗎？

的確。但是通常來講，事情並沒有那麼簡單。內容與表現（presentation）相分離是件好事，但CSS從HTML中獨立出來並不意味著內容也需要從表現中分離。換句話說，如果CSS請求深入分析HTML架構，那麼從HTML中分拆所有的顯示代碼並不一定會實現所有的目標。

此外，HTML很少會只包含內容，也表示整體架構。通常，架構是會包含container元素，允許CSS隔離一些固定元素。即使沒有表象類（presentational classes），也能混合HTML清晰地把內容展示出來。

我相信，鑒於當前的HTML和CSS狀態，把HTML和CSS明智地結合起來，當做表現層是非常需要的。而通過模板和局部模板（partials）也可以把內容層進行分離。 

4.解決方案。

如果把HTML和CSS結合起來，作為一個Web應用程式的表現層，那麼它們需要採取一些方式更好地促進優秀CSS架構的形成。

最好的方法是CSS中儘可能少的包含HTML架構。CSS則是應該定義元素的視覺效果，無論該視覺元素在哪裡。如果有一些特定的組件需要在不同的場合顯示不同的效果，那麼應該賦予不同的名稱。例如，CSS通過.button類別選取器定義了一個按鈕組件。如果HTML想要一個特定的元素看起來像按鈕，那麼就可以使用.button。如果這裡有特殊要求，這裡的按鈕與其他的有所不同（有可能更大和寬些），那麼CSS需要定義一個新的類，HTML可以使用新的類來賦予該元素新的視覺效果。

CSS賦予元素的外在特徵，HTML在頁面上進行調用。更少的CSS能被更多的HTML架構調用是最好的。

準確地在HTML中聲明元素不僅可以清晰表達設計意圖，其他開發人員也可以清晰地查看標記並且知道元素將呈現的樣子。如果沒有這種實踐，它很難區分一個元素的外觀設定是有意或無意的，這樣很容易導致團隊混亂。

在標記中填入大量的類(classes)是種常見缺陷，這樣做往往需要花費額外的精力。一個CSS樣式可以給一個特定組件引用上千次。那麼，為了在標記裡面進行顯示聲明，就真的值得去重複編寫這樣的類嗎？

雖然這種擔心是有效，但它可能會產生誤導。言下之意就是無論你在CSS中使用一個父選取器還是親手編寫上千個Class，這裡都會有些額外的選擇。在Rails或者其他架構裡查看同層級抽象很大程度上可以在HTML中保持很好的視覺外觀，並且無需在類中一遍又一遍地編寫相同的類。

5.最佳實務。

針對上面的種種錯誤，我進行了很好地總結，並且根據自身經驗提出了一些建議，希望它們能協助您更好地實現良好的CSS架構目標。

專註

確保選取器對一些元素不進行無關樣式的最好方法是不給它們機會。例如像#main-nav ul li ul li div這樣的選取器可能很容易地應用於不想要的元素上。另一方面，像.subnav這樣的選取器就不會給它們任何機會。把類別選取器直接應用於你想要的元素上是最好的方式，並且可以保持元素的可預測性。

1. /* Grenade */ 
2. #main-nav ul li ul { }  
3.  
4. /* Sniper Rifle */ 
5. .subnav { } 

模組化

一個組織圖良好的組件層可以協助解決HTML架構與CSS那種鬆散的耦合性。此外，CSS組件本身應該是模組化的。組件應該知道如何進行樣式和更好地工作，但是關於布局、定位以及它們與周圍元素的關係不應該做太多的假設。

一般而言，CSS要定義的應該是組件的外觀，而不是布局或者位置。同樣在使用background、color和font這些屬性時也要遵循原則使用。

布局和位置應當由一個單獨的布局類或者單獨的容器元素構成（請記住，有效地把內容與展示進行分離其實就是把內容與容器進行分離）。

給類進行命名空間

我們已經檢查出為什麼父選取器不能在封閉和防止交叉樣式汙染上面發揮100%的功效。而一個更好的解決方案就是在類上應用命名空間。如果一個元素是可視化組件的一員，那麼該元素的每個子項目都應該使用基於命名空間的組件。

1. /* High risk of style cross-contamination */ 
2. .widget { }  
3. .widget .title { }  
4.  
5. /* Low risk of style cross-contamination */ 
6. .widget { }  
7. .widget-title { } 

給類進行命名空間可以保持組件獨立性和模組化。它可以把現有類衝突降至最小並且減少子項目的一些特殊要求。

建立修飾符類來向外延展群組件

當一個現有組件需要在一個特定的語境中有所不同時，可以建立一個修飾符類（modifier class）來擴充它。

1. /* Bad */ 
2. .widget { }  
3. #sidebar .widget { }  
4.  
5. /* Good */ 
6. .widget { }  
7. .widget-sidebar { } 

正如我們看到的，基於父元素的缺點對組件進行修改，需要重申：一個修飾符類可以在任何地方使用。基於位置的覆蓋只能被用在一個特定的位置，修飾符類也可以根據需要被多次使用。顯然，修飾符類是符合HTML開發人員需求的。

把CSS組織成邏輯結構

Jonathan Snook在其非常優秀的《SMACSS》書中提到，CSS可以被分成四個不同的類：基礎（base）、布局（layout）、模組（modules）和狀態（state）。基礎包括了複位原則和元素預設值；布局是對網站範圍內的元素進行定位以及像網格系統那樣作為一種通用布局助手；模組即是可重用的視覺元素；狀態即指樣式，可以通過JavaScript進行開啟或關閉。

組件是一個獨立的視覺元素。模板在另一方面則是構建塊。模板很少獨自站在自己的角度去描述視覺和感覺，相反，它們是單一的、可重用的模式，可以放在一起形成組件。

為了提供更詳細的例子，一個組件可能就是一個強制回應對話方塊。該模式可能在頭部包含漸層的網站簽名、或者在周圍會有陰影、在右上方會有關閉按鈕、位置固定在垂直與水平線中間。這四個模式可能被網站重複多次使用，所以在每次使用的時候，你都很少會想到重新編碼與設計。這些所有的模板即形成了一個模組組件。

因樣式和風格使用類

有過大型網站建設的人可能有個這樣的經驗，一個擁有類的HTML元素可能完全不知道其用途。你想刪除它，但是又猶豫不決，因為它的作用你可能還未意識到。一旦這樣的事情一遍又一遍發生的時候，隨著時間的推移，項目中將會有越來越多這樣的類，只因為團隊成員都不敢刪除。

在Web前端開發中，類承擔了太多的責任，因此才會產生這樣的問題。樣式化HTML元素、扮演著JavaScript hook角色、功能檢測、自動化測試等。當這麼多應用程式在使用類時，讓你從HTML中刪除它們將會變的非常艱難。

然而，使用一些成熟的約定（慣例）即可完全避免這種問題。當在HTML中看到一個類時，你應該立即明白它的目的。我建議在前面使用首碼，例如用於JavaScript的在前面加.js，表示Modernizr classes可以在前面加.supports，沒有加首碼的即用於表示樣式。

這樣來發現未使用的類和從HTML中移除它們將會變得非常簡單。你甚至可以自動完成這一個過程，在JavaScript中通過交叉引用HTML中的document.styleSheets對象。如果在document.styleSheets中沒有發現該類，即可安全移除。

一般來說，最佳做法是把內容與示範相分離，另外把功能分離開來也同樣重要。使用樣式類像JavaScript hook在某種程度上可以加深CSS與JavaScript之間的耦合，但在不打破功能性的前提下很難或者根本不可能更改外觀。 

有邏輯的命名類

大多數寫CSS的人喜歡使用連字號來分隔命名詞，但連字號並不足以區分不同類型之間的類。

Nicolas Gallagher最近針對遇到的問題寫了一個解決方案，並且取得了巨大的成功（略有改動），為了說明命名規範，可以考慮以下格式：

1. /* A component */ 
2. .button-group { }  
3.  
4. /* A component modifier (modifying .button) */ 
5. .button-primary { }  
6.  
7. /* A component sub-object (lives within .button) */ 
8. .button-icon { }  
9.  
10. /* Is this a component class or a layout class? */ 
11. .header { } 

從上述類中可以發現其很難正確區分類型規則。這不但會困惑，而且連自動化的測試CSS和HTML也變的很難。一個結構化的命名規範應該是初看就能夠知道其類名與其他類之間的關係，並且知道它出現在HTML中的位置——使命名更加簡單和容易測試。

1. /* Templates Rules (using Sass placeholders) */ 
2. %template-name  
3. %template-name--modifier-name  
4. %template-name__sub-object  
5. %template-name__sub-object--modifier-name  
6.  
7. /* Component Rules */ 
8. .component-name  
9. .component-name--modifier-name  
10. .component-name__sub-object  
11. .component-name__sub-object--modifier-name  
12.  
13. /* Layout Rules */ 
14. .l-layout-method  
15. .grid  
16.  
17. /* State Rules */ 
18. .is-state-type  
19.  
20. /* Non-styled JavaScript Hooks */ 
21. .js-action-name 

重做第一個例子：

1. /* A component */ 
2. .button-group { }  
3.  
4. /* A component modifier (modifying .button) */ 
5. .button--primary { }  
6.  
7. /* A component sub-object (lives within .button) */ 
8. .button__icon { }  
9.  
10. /* A layout class */ 
11. .l-header { } 

6.工具

維護一個高效且組織良好的CSS架構是非常困難的，尤其是在大型團隊中。下面向大家推薦幾款很好的工具來幫你管理網站CSS架構。

CSS Preprocessor

CSS前置處理器採用PHP5編寫，有前置處理器的常見功能，可以幫你快速編寫CSS。另外有些號稱“功能”的前置處理器實際上並不會對CSS架構產生良好作用。下面我提供一個列表，在使用時一定要避免：

• 切勿純粹為了組織代碼來嵌套規則。只有當輸出你真正想要的CSS時才可以。
• 在無需傳遞參數的時候切勿使用mixin，不帶參數的mixin更適合用作模板，易擴充。
• 切勿在選取器上使用@extend，它不是個單一的類。從設計角度來看是毫無意義的，它會膨脹編譯過的CSS。
• 在運用組件修飾符規則時，切勿使用@extend UI組件，這樣會失去基礎鏈。

@extend和%placeholder是前置處理器裡面非常好的兩個功能。它們可以幫你輕鬆管理CSS抽象並且無需添加bloat和大量的基類到CSS和HTML裡，否則將會很難管理。

當你初次使用@extend時，常會與修飾符類一起使用，例如：

1. .button {  
2.   /* button styles */ 
3. }  
4.  
5. /* Bad */ 
6. .button--primary {  
7.   @extend .button;  
8.   /* modification styles */ 
9. } 

這樣做會讓你在HTML中失去繼承鏈。很難使用JavaScript選擇所有的按鈕執行個體。

作為一般規則，很少去擴充UI組件或者在知道類型後做些什麼。這是區分模板和組件的一種方式，模板無需參與到應用程式的邏輯，並且可以使用前置處理器進行安全擴充。

下面是一個引用上面的模式例子：

1. .modal {  
2.   @extend %dialog;  
3.   @extend %drop-shadow;  
4.   @extend %statically-centered;  
5.   /* other modal styles */ 
6. }  
7.  
8. .modal__close {  
9.   @extend %dialog__close;  
10.   /* other close button styles */ 
11. }  
12.  
13. .modal__header {  
14.   @extend %background-gradient;  
15.   /* other modal header styles */ 
16. } 

CSS Lint

CSS Lint是由Nicole Sullivan和Nicholas Zakas編寫的一款代碼品質偵查工具，協助CSS開發人員寫出更好的代碼。他們的網站上是這樣介紹CSS Lint的：

CSS Lint是一個用來幫你找出CSS代碼中問題的工具，它可做基本的語法檢查以及使用一套預設的規則來檢查代碼中的問題，規則是可以擴充的。

使用CSS Lint建議：

1. 不要在選取器中出現ID。
2. 在多部分規則中，不要使用非語義（non-semantic）類型選取器，例如DIV、SPAN等。
3. 在一個選取器中使用的串連符（combinator）不要超過2個。
4. 任何類名都不要以“js-”開始。
5. 如果在非“I-”首碼規則裡經常使用布局和定位應給予警告
6. 如果一個類定義後被重新定義成子類，也應給予警告。

總結

CSS不僅僅是視覺設計，也不要因為你編寫CSS就隨便拋出編程的最佳實務。像OOP、DRY、開啟/閉合、與內容分離等這些規則應該應用到CSS裡面。無論你如何組織代碼，都要確保方法真正協助到你，並且使你的開發更加容易和可維護的。

 摘自：http://www.csdn.net/article/2012-11-30/2812325-CSS-Architecture