Philip Walton 在AppFolio擔任前端工(gōng)程師，他在Santa Barbara on Rails的聚會上提出了CSS架構和一(yī)些最佳實踐，并且在工(gōng)作中(zhōng)一(yī)直沿用。

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

有趣的是，我(wǒ)們很少這樣去(qù)評價其他語言。Rails開(kāi)發人員(yuán)并不會因爲其代碼比較規範，就認爲他是一(yī)名優秀的開(kāi)發人員(yuán)。這僅僅是個基準。當然，他的代碼得必須規範。另外(wài)，還需集合其他方面考慮，比如代碼是否可讀？是否容易修改或擴展……

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

1.良好的CSS架構目标

在CSS社區，很難提出某個最佳實踐已經成爲大(dà)家的普遍共識。純粹地從Hacker News的評論上判斷和開(kāi)發者們對CSS Lint發布後的反應來看，大(dà)多數人對基本的CSS東西是持反對意見的。所以，并不是爲自己的最佳實踐奠定一(yī)套基本的論據，而應該确定真正的目标。

好的CSS架構目标并不同于開(kāi)發一(yī)個好的應用程序，它必須是可預測、可重用、可維護和可伸縮的。

可預測

可預測意味着可以像預期的那樣規範自己的行爲。當你添加或者修改某個規則時，它并不會影響到沒有指定的部分(fēn)。對于一(yī)個小(xiǎo)網站來說，一(yī)些微乎其微的改變并不算什麽。而對于擁有成千上萬個頁面的大(dà)網站來說，可預測卻是必須的。

可重用

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

可維護

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

可擴展

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

2.常見的錯誤實踐

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

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

幾乎在每個網站上，都會有一(yī)個特定的虛拟元素看起來與其他頁面是完全一(yī)樣的，然而隻有一(yī)個頁面除外(wài)。當面對這樣一(yī)種情況時，幾乎每個新手CSS開(kāi)發人員(yuán)（甚至是經驗豐富的）都會以同樣的方式來修改。你應該爲該頁面找出些與衆不同之處（或者自己創建），然後再寫一(yī)個新規則去(qù)操作。

基于父組件來修改組件

.widget {

background： yellow;

border： 1px solid black;

color： black;

width： 50%;

}

#sidebar .widget {

width： 200px;

}

body.homepage .widget {

background： white;

}

初看，這絕對是段無害的代碼，但讓我(wǒ)們來看看它是否達到了我(wǒ)們所設置的目标。

首先，widget在examle是不可預見的。當這些小(xiǎo)部件出現在頁面兩側或者主頁面時，開(kāi)發人員(yuán)期望它們以某種特定的方式顯示出來，且又(yòu)不失特色。另外(wài)，它也是不可重用或不可擴展的。

另外(wài)，它也比較難維護。一(yī)旦這個widget需要重新設計，那麽你不得不修改其他幾個CSS樣式。想象一(yī)下(xià)，如果這段代碼是使用其他語言編寫的，它基本就是一(yī)個類定義，然後在代碼的另一(yī)部分(fēn)使用該類定義并做出擴展。這直接違反了軟件開(kāi)發的開(kāi)放(fàng)/閉合（open/close）原則。

過于複雜(zá)的選擇器

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

但伴随着越深入的開(kāi)發，我(wǒ)越會遠離(lí)這種複雜(zá)的選擇器。一(yī)個選擇器越複雜(zá)，與HTML就越耦合。依靠HTML标簽和組合器可以保持HTML代碼幹幹淨淨，但卻讓CSS更加毛重和淩亂。

#main-nav ul li ul li div { }

#content article h1:first-child { }

#sidebar > div > h3 + p { }

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

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

上面提到的例子都是不具備可預測性、可重用、可擴展和可維護這四大(dà)特性的。例如第一(yī)個選擇器（下(xià)來菜單）例子，如果一(yī)個外(wài)觀非常相似的下(xià)拉列表需要用在不同的頁面上，并且#main-nav并不屬于内部元素，那麽你是否需要重新設計？假設開(kāi)發者想要修改第三個例子裏div裏面部分(fēn)标記，那麽整個規則都會被打破。

過于通用的類名

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

。..

Lorem ipsum dolor sit amet， consectetur adipiscing elit.

In condimentum justo et est dapibus sit amet euismod ligula ornare.

Vivamus elementum accumsan dignissim.

Click Me！

.widget {}

.widget .title {}

.widget .contents {}

.widget .action {}

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

在一(yī)些大(dà)型項目上，像.title這樣的名稱很有可能會被用在另外(wài)一(yī)個頁面或者本身。如果這樣的情況發生(shēng)，那麽整個标題部分(fēn)明顯會和預期的不一(yī)樣。

過于通用的類選擇器名稱會導緻許多不可預測的CSS樣式發生(shēng)。