在現時瀏覽器存在廣泛支持的前提下，css被我們給予了前所未有的重大責任。不過倚賴css越多，式樣表文件便會變得越大越復雜。與此同時，文件保護和團體的考驗也隨之而來。
（時過不久）只要一個css文件就夠了——全部規則（rule）萃聚一堂，增去掉並改動都很便捷——可這種日期早已遠去。（如今）樹立新網站時，務必花點時間好好運籌怎麼團體和架構css。
構建css系統的第1步是大綱的擬訂。（我覺得）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值，在這以後的某天無意間又加了一個（或前或後）。（這種事情狀況下）後一個屬性天然會起效用。如果不曉得第二個屬性存在，無論我怎麼調試第1個屬性值、按F5瀏覽器，也看不到頁面變動。（htmlor注：這個問題我深有體驗領會）假如依照字母順著次序排列，你便會發覺margin被定義了兩次（由於他們挨在一塊兒），這個問題天然可以防止。
優先項
當網站復雜、涉及非常多css文件時，會樹立數量多的附屬關系。一朝需求定制某個元素特有的式樣，!important選項仿佛好象是最佳挑選。沒錯，!important是能解一時之需，但最好搞明白造成問題的溯源，而後依據級聯關系表決是否實在需求用它。
假如你對上文提到的特別優異性、級聯和秉承很知道得清楚，大可不需要抱著!important一顆樹不放。（htmlor注：整片大片樹木等著你~）當然它仍然會派上用途，然而運用之前要對具體事情狀況明白於胸。務必不要由於不知問題的癥結算後餘下在的地方而把!important當作近路或是彌補方案。
小結
當我們變得倚賴css而使式樣表一天一天慢慢地復雜時，就需求准確的規劃來防止犯錯，並使代碼便於保護。既是完美無損的方案並不存在，那末理解css的辦公形式以及文件、挑選器和屬性的多種團體方案，沒有疑問有助於我們開具優質的代碼，禁受住時間考驗。
小站： 期望大家提指教