CSS架構目標

　　Philip Walton 在AppFolio擔任前端工程師，他在Santa Barbara on Rails的聚會上提出了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開發人員（甚至是經驗豐富的）都會以同樣的方式來修改。你應該為該頁面找出些與眾不同之處（或者自己建立），然後再寫一個新規則去操作。

　　基於父元件來修改元件

.widget {  
  background: yellow;  
  border: 1px solid black;  
  color: black;  
  width: 50%;  
}  

#sidebar .widget {  
  width: 200px;  
}  

body.homepage .widget {  
  background: white;  
}

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

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

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

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

　　過於複雜的選擇器

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

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

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

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

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

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

　　過於通用的類名

　　當建立可重用的設計元件時，在元件的類選擇器中覆蓋附件的子元素是很常見的現象。例如：

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

.widget {}  
.widget .title {}  
.widget .contents {}  
.widget .action {}

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

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

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

　　一個規則做太多事

　　有時，你要在網站的左上角區域做一個20pixels的視覺化元件。

.widget {  
  position: absolute;  
  top: 20px;  
  left: 20px;  
  background-color: red;  
  font-size: 1.5em;  
  text-transform: uppercase;  
}

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

　　問題的關鍵是你讓.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這樣的選擇器就不會給它們任何機會。把類選擇器直接應用於你想要的元素上是最好的方式，並且可以保持元素的可預測性。

/* Grenade */ 
#main-nav ul li ul { }  

/* Sniper Rifle */ 
.subnav { }

　　模組化

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

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

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

　　給類進行名稱空間

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

/* High risk of style cross-contamination */ 
.widget { }  
.widget .title { }  

/* Low risk of style cross-contamination */ 
.widget { }  
.widget-title { }

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

　　建立修飾符類來擴充套件元件

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

/* Bad */ 
.widget { }  
#sidebar .widget { }  

/* Good */ 
.widget { }  
.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最近針對遇到的問題寫了一個解決方案，並且取得了巨大的成功（略有改動），為了說明命名約定，可以考慮以下格式：

/* A component */ 
.button-group { }  

/* A component modifier (modifying .button) */ 
.button-primary { }  

/* A component sub-object (lives within .button) */ 
.button-icon { }  

/* Is this a component class or a layout class? */ 
.header { }

/* Templates Rules (using Sass placeholders) */ 
%template-name  
%template-name--modifier-name  
%template-name__sub-object  
%template-name__sub-object--modifier-name  

/* Component Rules */ 
.component-name  
.component-name--modifier-name  
.component-name__sub-object  
.component-name__sub-object--modifier-name  

/* Layout Rules */ 
.l-layout-method  
.grid  

/* State Rules */ 
.is-state-type  

/* Non-styled JavaScript Hooks */ 
.js-action-name

/* A component */ 
.button-group { }  

/* A component modifier (modifying .button) */ 
.button--primary { }  

/* A component sub-object (lives within .button) */ 
.button__icon { }  

/* A layout class */ 
.l-header { }

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

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

.button {  
  /* button styles */ 
}  

/* Bad */ 
.button--primary {  
  @extend .button;  
  /* modification styles */ 
}

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

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

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

.modal {  
  @extend %dialog;  
  @extend %drop-shadow;  
  @extend %statically-centered;  
  /* other modal styles */ 
}  

.modal__close {  
  @extend %dialog__close;  
  /* other close button styles */ 
}  

.modal__header {  
  @extend %background-gradient;  
  /* other modal header styles */ 
}

　　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裡面。無論你如何組織程式碼，都要確保方法真正幫助到你，並且使你的開發更加容易和可維護的。

　　英文原文：CSS Architecture