本文向大家描述一下如何合理架構CSS，構建CSS系統的***步是大綱的擬定，CSS組織規劃的重要性堪比網站目錄結構，沒有哪種方案放之四海而皆準，因此我們會討論一些基本的組織方案，以及它們各自的利弊。

DIV CSS網頁布局時如何合理架構CSS？

當前瀏覽器普遍支持的前提下，CSS被我們賦予了***的使命。然而依靠CSS越多，樣式表文件就會變得越大越復雜。與此同時，文件維護和組織的考驗也隨之而來。(曾幾何時)只要一個CSS文件就夠了——所有規則(rule)匯聚一堂，增刪改都很方便——可這種日子早已遠去。(現在)建立新網站時，必須花點時間好好籌劃怎么組織和架構CSS。

文件的組織

　　構建CSS系統的***步是大綱的擬定。(我認為)CSS組織規劃的重要性堪比網站目錄結構。(htmlor注:用詞夸張一點，讓你加深記憶)沒有哪種方案放之四海而皆準，因此我們會討論一些基本的組織方案，以及它們各自的利弊。

主CSS文件

　　通常可以使用一個主CSS文件，來放置所有頁面共享的規則。這個文件會包含默認的字體、鏈接、頁眉和其他等樣式。有了主CSS文件之后，我們開始探討高級組織策略。

方法一:基于原型

　　最基本的策略是基于原型頁面(archetypepage)分離CSS文件。假如一個網站的首頁、子頁面和組合頁設計不同，就可以采用基于原型的策略。(這種策略下)每個頁面都會有專屬的CSS文件。

　　在原型數量不多的情況下，這個方法簡單明了、行之有效。然而，當頁面元素并不按部就班的位于各個原型頁時，問題就出現了。假如子頁面和組合頁共享某些元素，而首頁卻沒有，我們應該怎么做呢?

　　把共享元素放入主CSS文件。這雖不是最純正的解決辦法，卻適用于某些具體情況。可是假如網站龐大，(這樣做的話)主CSS文件會迅速膨脹——這就違反了分離文件的初衷:避免導入不必要的大文件。

　　在組合頁和子頁面的CSS文件里各放一份樣式代碼。(這么做)就意味著要維護冗余代碼，很顯然我們不想這樣。

　　創建一個新的文件，由這兩種頁面共享。這聽起來不錯。不過假如只有10行代碼，我們創建這個文件僅僅是為了共享這10行代碼?(htmlor注:殺雞用牛刀?)這方法很純粹，但假如網站龐大有很多對頁面共享很少量元素時(htmlor注:比如30對頁面分別共享10行代碼)，就顯得很粗笨了。

　　創建一個單獨的CSS文件，包含所有共享元素的樣式。這方法可能比較簡單，卻要取決于網站的大小和共享元素的多少。有種情況會很煩:導入了一個很大的CSS文件，但頁面只用到一小部分樣式——還是那句話，這違反了分離文件的初衷。

　　這就是我所說的重疊的兩難(overlapdilemma)。零碎CSS規則的重疊不一而足，并沒有一個完全清楚無誤的方案來組織它們。

方法二:基于頁面元素/塊

　　假如網站使用服務器端include，這個方法會很不錯。舉例說明，假如使用頁眉include，它會有自己相應的CSS文件。頁腳或者其他部分的include可以如法炮制，只須導入自己的CSS文件。這個方法簡單干凈，不過可能會產生很多小CSS文件。

　　舉例來說，假如頁腳的樣式只需要20行CSS代碼，單***建一個文件就劃不來了。而且這個方法會導致每個頁面都包含一堆CSS文件——因為有多少include，就得有多少CSS文件。

方法三:基于標記

　　這個方案直觀實際，與前一個類似。假如網站共有30個頁面，其中10個含有form，那么可以創建一個CSS文件專門處理form的樣式，只在這10個頁面導入它。假如另外10個頁面含有table，就創建一個文件專門處理table樣式……諸如此類。

另外的組織技巧

　　除了用主觀的方法組織文件，我們還要考慮如打印、手持設備和屏幕等多種媒體類型。這雖然已經很清楚的定義過，可依舊是建立文件結構時應該考慮的一個因素。一旦必須支持多種媒體類型，主CSS文件里的某些規則可能就得重新考慮。

　　另外，品牌聯合也可能是一個重要因素。(htmlor注:如google和nike聯手推出的joga)假如涉及品牌聯合，你就得考慮哪些元素應該調整以適應另一品牌。比如分別使用不同的CSS文件等。

　　還有一個常被忽略的技巧:使用嵌套的@import語句。只包含一連串@import語句，或者再加幾句CSS規則，就能創建一個CSS文件。用這個方法完全可以創建網站的主CSS文件(用@import導入各部分的樣式文件)。假如網站的每個頁面都導入了4到5個不同的CSS文件，無疑你應該考慮使用這個技巧。#p#

規則和選擇器的組織

　　談完了文件組織，接著討論一下怎么組織文件里的東西吧。很自然，我們希望在文件里暢通無阻的瀏覽，迅速找到要編輯的選擇器(selector)或規則。

冗余vs附屬

　　正如DaveShea在其文章《冗余vs.附屬》(Redundancyvs.Dependency)里所說的，你必須不斷了解級聯(cascade)。你要決定是對選擇器編組(意味著附屬)，還是把它們分離(意味著冗余)。編組可以保持代碼簡潔扼要，可是會建立附屬關系，導致維護開銷增加。假如不編組，就會增加文件大小，讓相似的選擇器保持一致變得困難。只有做好這種權衡、取舍，才能每次都作出正確的決定。

按相互關系/上下文編組

　　既然文件組織可以是主觀的，那么顯然，按照規則和選擇器與其他部分的相互關系來進行編組是***的方法。舉例說明，假設你用容器、頁眉和頁腳來完成布局，就應該把它們編成一組。

　　這似乎很簡單，其實不然。比如，把頁眉中的導航加入CSS時，是將它跟父元素編組還是獨立編組?這種情況下，要視乎規則的上下文。通常，頁眉與頁面布局相關，應該與其他布局元素一起編組。而導航是頁眉的一塊，應該和頁眉的其他塊編組，而不是頁眉本身。

使用注釋

　　跟大多數代碼類似，注釋是組織良好與否的要害。應該根據CSS的控制范圍，清楚的標注每節(section)。***確保注釋視覺突出，以便在內容滾動、一目十行時快速定位。

　　DougBowman在其文章《CSS組織技巧之一:標記》(CSSorganizationTip#1:Flags)里把CSS注釋玩得高明之極。他具體說明了在節名之前加上等號，以便使用文本編輯器的查找功能迅速跳到某節。

　　你應該細致認真的了解了特異性、級聯和繼續，并善用它們。它們之中的每一項都可以是你最可怕的敵人，也可以是你最友善的朋友。當建立龐大的網站時，是否理解這些細微精妙之處，決定了你所構建的是堅如磐石的系統，還是經不起風雨的豆腐渣工程。(htmlor注:這句完全意譯，比較爽)

屬性的組織

　　現在我們了解了文件的組織，也知道了文件內規則的組織，但還有一個重要的組織環節(沒有提到)，那就是屬性(attribute)。雖然屬性比前兩個概念更簡單，可是還有一些非常好的、能夠保持規則整潔的方法很值得一提。

按字母排序

　　提到屬性，假如說需要遵循什么原則的話，那就是:按-字-母-排-序。其實這招對于屬性瀏覽幫助不大，不過可以防止屬性值覆蓋這種偶然事件的發生。

　　舉個例子吧，已經數不清有多少次，我為某個選擇器定義過了margin值，之后的某天無意間又加了一個(或前或后)。(這種情況下)后一個屬性自然會起作用。假設不知道第二個屬性存在，不管我怎么調整***個屬性值、刷新瀏覽器，也看不到頁面變化。(htmlor注:這個問題我深有體會)假如按照字母順序排列，你就會發現margin被定義了兩次(因為它們挨在一起)，這個問題自然可以避免。

優先項

　　當網站復雜、牽涉太多CSS文件時，會建立大量的附屬關系。一旦需要定制某個元素特有的樣式，!important選項似乎是***選擇。沒錯，!important是能解一時之需，但***搞清楚導致問題的根源，然后根據級聯關系決定是否真的需要用它。

　　假如你對上文提到的特異性、級聯和繼續很熟悉，大可不必抱著!important一顆樹不放。(htmlor注:整片森林等著你~)當然它還是會派上用場，不過使用之前要對具體情況了然于胸。千萬不要因為不知問題的癥結所在而把!important當作捷徑或是補救方案。

小結

　　當我們變得依靠CSS而使樣式表日漸復雜時，就需要正確的計劃來避免犯錯，并使代碼易于維護。既然***無缺的方案并不存在，那么了解CSS的工作方式以及文件、選擇器和屬性的多種組織方案，無疑有助于我們寫出優質的代碼，經受住時間考驗。
 

【編輯推薦】

1. 調用DIV+CSS實現模擬表格對角線
2. JavaScript動態創建div屬性和樣式
3. SPAN元素和DIV元素的區別
4. CSS2.0中page-break-after屬性用法
5. 探究CSS中border:none;與border:0;的區別