發布日期：2017/6/18

百度權重查詢 站長交易 友情鏈接交換 網站監控 服務器監控 seo監控

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）也可以把內容層進行星散。

1 2 下一頁