團隊開發中的CSS規範總結

互連網上有許多通用的方案，這裡我著重提三點：

 

1.模組化CSS，提高代碼重用    我們知道，一個成熟的網站需要有統一的風格，一致的使用者體驗，比如：網站的配色，字型的大小，互動行為一致等應該在設計之初就得到確定，而不是由個體開發人員來自由的定義。網站同時應存在可以提取出來公用的樣式部分（如人人網中個人首頁右側的”最近來訪“，”推薦“等處的容器和標題都是相同的展示效果）。那麼我們就可以把網站的字型大小，公用控制，共用模組的樣式都抽離出來，作為單獨的模組來處理。這樣，團隊中的每個人如果需要這樣的樣式，都可以用這種公用樣式，以此提高代碼的重用率。    我認為一個項目的CSS可以拆分成2部分： 公用CSS和業務CSS。我們在項目中抽出的這部分可以模組化的CSS就可以歸類為公用CSS。這部分的代碼命名不應涉及到具體的業務，只應對其在模組中負責的具體邏輯負責。

    對於業務CSS，我們需要有統一的命名。如一個網站中有如下幾個欄目：檔案，社區，社交關係等，在專案規劃時，就需要把這塊模組的名稱定好，比如 檔案-files,社區-cmty(community簡寫)，這樣開發人員在寫樣式時，就可以使用公用的首碼，.cmty-cmtydetail，而不會根據各自的想法，寫成.community或是.commu，這一點對於統一風格是盡為重要的，也方便備用人員接手工作。 

關於這方面，可以看看網上關於 物件導向的CSS / OOCSS

 

    

 

2.CSS合并、壓縮    顧名思義，在團隊開發中，開發人員會分別處理各自單元的樣式，網站上線了，為了減少http串連數，我們需要把這些CSS合并起來做為一個檔案來載入，同時，我們在開發時可能會加入一些注釋和行縮排，這些都會浪費我們的頻寬，我們需要把合并後的CSS檔案再進行壓縮，事實上，這樣的最佳化效果也是十分明顯的，檔案大小會節約至少20%。    目前互連網上對CSS合并的處理有兩種：靜態合并和動態合并。靜態合并是指在網站部署上線前，已經完成了CSS的合并，並產生一個靜態檔案，動態合并是配合後端檔案而實現的合并，既請求CSS時，把需要合并的所有CSS名稱做為參數，傳給一個後端檔案（asp,php,aspx等），由該後端檔案動態產生合并後的樣式並輸出。兩種方案各有利弊。

    我在這裡想表達的是，我們在項目中應根據項目的類型，應用不同的合并方案，門戶型網站對首次載入速度要求較高，我們並不需要合并所有的CSS進來，而社區型的網站，使用者需要登入才可以訪問，那麼就可以利用使用者輸入的時間載入所有的CSS進來，在以後的訪問中都可以省去CSS請求的時間。

 

3.統一CSS書寫規範    好處是不言而喻的，無論是後台前台，統一的代碼規範是必須的。1.一律使用小字字母2.盡量使用ShortHand形式,在font,margin,padding,background中3.處理父子關係的節點時，使用 .parent-child-grandson（大多時候parent名稱與具體業務的模組名稱相關） 寫法 ，而不使用 .parent .child .grandson，事實證明後者在在團隊開發中更容易造成模組間的樣式覆蓋，同時也更不易於閱讀。一個簡單的例子：在模組一中有一列表，用第二種寫法大致如下：.informationlist{}.informationlist .listitem{}而同時，在模組二中也存在一列表，開發人員正好也用到了.listitem，而且認為這個命名不常見，前面沒有加上限定，直接使用了.listitem ，這樣就極容易造成了樣式衝突。或許您提出不同意見：我們強制讓所有的樣式前面都加一個關於其模組名的限定，把模組二中的.listitem改成 .module2 .listitem，不就ok了？但這樣並不好，因為在實際應用中，不能要求所有的樣式寫法一定要加上模組限定，比如在body節點下的某個浮動節點，我們就不能這樣處理。同時，針對第一種寫法，我們還可以很輕鬆開發出一個CSS的檢測軟體，用來檢測文法，判斷覆蓋。（我們知道判斷出.a .b, .a>b,.b的覆蓋關係遠比.a-b複雜的多）