大型網站，CSS組織架構

在做大型的項目的時候，前期，一定要做好規劃，，有條有理的進行之中。。。CSS檔案也是這樣，一般在做這種項目的時候，網站都會有一個專門放置CSS的檔案夾。。
----------------------------------------------------------------------------------------------------------------------------

在當前瀏覽器普遍支援的前提下，css被我們賦予了前所未有的使命。然而依賴css越多，樣式表檔案就會變得越大越複雜。與此同時，檔案維護和組織的考驗也隨之而來。

(曾幾何時)只要一個css檔案就夠了——所有規則(rule)匯聚一堂，增刪改都很方便——可這種日子早已遠去。(現在)建立新網站時，必須花點時間好好籌劃怎麼組織和架構css。

檔案的組織

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

主css檔案

通常可以使用一個主css檔案，來放置所有頁面共用的規則。這個檔案會包含預設的字型、連結、頁首和其他等樣式。有了主css檔案之後，我們開始探討進階組織策略。

方法一:基於原型

最基本的策略是基於原型頁面(archetype page)分離css檔案。假如一個網站的首頁、子頁面和組合頁設計不同，就可以採用基於原型的策略。(這種策略下)每個頁面都會有專屬的css檔案。

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

把共用元素放入主css檔案。這雖不是最純正的解決辦法，卻適用於某些具體情況。可是如果網站龐大，(這樣做的話)主css檔案會迅速膨脹——這就違背了分離檔案的初衷:避免匯入不必要的大檔案。

在組合頁和子頁面的css檔案裡各放一份樣式代碼。(這麼做)就意味著要維護冗餘代碼，很顯然我們不想這樣。

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

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

這就是我所說的重疊的兩難(overlap dilemma)。零碎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檔案，無疑你應該考慮使用這個技巧。

規則和選取器的組織

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

冗餘 vs. 附屬

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

按相互關係/上下文編組

既然檔案組織可以是主觀的，那麼顯然，按照規則和選取器與其他部分的相互關係來進行編組是最好的方法。舉例說明，假設你用容器、頁首和頁尾來完成布局，就應該把它們編成一組。

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

使用注釋

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

Doug Bowman在其文章《css組織技巧之一:標記》(CSS Organization Tip #1: Flags)裡把css注釋玩得高明之極。他詳細說明了在節名之前加上等號，以便使用文字編輯器的尋找功能迅速跳到某節。

別忘了

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

屬性的組織

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

按字母排序

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

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

優先項

當網站複雜、牽涉太多css檔案時，會建立大量的附屬關係。一旦需要定製某個元素特有的樣式，!important選項似乎是最佳選擇。沒錯，!important是能解一時之需，但最好搞清楚導致問題的根源，然後根據級聯關係決定是否真的需要用它。

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

小結

當我們變得依賴css而使樣式表日漸複雜時，就需要正確的計劃來避免犯錯，並使代碼易於維護。既然完美無缺的方案並不存在，那麼瞭解css的工作方式以及檔案、選取器和屬性的多種組織方案，無疑有助於我們寫出優質的代碼，經受住時間考驗。