互聯(lián)網(wǎng)上有許多通用的方案，這里我著重提三點：
1.模塊化CSS，提高代碼重用 我們知道，一個成熟的網(wǎng)站需要有統(tǒng)一的風格，一致的用戶體驗，比如：網(wǎng)站的配色，字體的大小，交互行為一致等應該在設計之初就得到確定，而不是由個體開發(fā)者來自由的定義。網(wǎng)站同時應存在可以提取出來公用的樣式部分（如人人網(wǎng)中個人主頁右側的”最近來訪“，”推薦“等處的容器和標題都是相同的展示效果）。那么我們就可以把網(wǎng)站的字體大小，公共控制，共用模塊的樣式都抽離出來，作為單獨的模塊來處理。這樣，團隊中的每個人如果需要這樣的樣式，都可以用這種公共樣式，以此提高代碼的重用率。 我認為一個項目的CSS可以拆分成2部分：公共CSS和業(yè)務CSS。我們在項目中抽出的這部分可以模塊化的CSS就可以歸類為公共CSS。這部分的代碼命名不應涉及到具體的業(yè)務，只應對其在模塊中負責的具體邏輯負責。
對于業(yè)務CSS，我們需要有統(tǒng)一的命名。如一個網(wǎng)站中有如下幾個欄目：文件，社區(qū)，社交關系等，在項目規(guī)劃時，就需要把這塊模塊的名稱定好，比如 文件-files,社區(qū)-cmty(community簡寫)，這樣開發(fā)人員在寫樣式時，就可以使用公用的前綴，.cmty-cmtydetail，而不會根據(jù)各自的想法，寫成.community或是.commu，這一點對于統(tǒng)一風格是盡為重要的，也方便備用人員接手工作。
關于這方面，可以看看網(wǎng)上關于 面向對象的CSS / OOCSS
2.CSS合并、壓縮 顧名思義，在團隊開發(fā)中，開發(fā)者會分別處理各自單元的樣式，網(wǎng)站上線了，為了減少http連接數(shù)，我們需要把這些CSS合并起來做為一個文件來加載，同時，我們在開發(fā)時可能會加入一些注釋和行縮進，這些都會浪費我們的帶寬，我們需要把合并后的CSS文件再進行壓縮，事實上，這樣的優(yōu)化效果也是十分明顯的，文件大小會節(jié)約至少20%。 目前互聯(lián)網(wǎng)上對CSS合并的處理有兩種：靜態(tài)合并和動態(tài)合并。靜態(tài)合并是指在網(wǎng)站部署上線前，已經(jīng)完成了CSS的合并，并生成一個靜態(tài)文件，動態(tài)合并是配合后端文件而實現(xiàn)的合并，既請求CSS時，把需要合并的所有CSS名稱做為參數(shù)，傳給一個后端文件（asp,php,aspx等），由該后端文件動態(tài)的生成合并后的樣式并輸出。兩種方案各有利弊。
我在這里想表達的是，我們在項目中應根據(jù)項目的類型，應用不同的合并方案，門戶型網(wǎng)站對首次加載速度要求較高，我們并不需要合并所有的CSS進來，而社區(qū)型的網(wǎng)站，用戶需要登錄才可以訪問，那么就可以利用用戶輸入的時間加載所有的CSS進來，在以后的訪問中都可以省去CSS請求的時間。
3.統(tǒng)一CSS書寫規(guī)范 好處是不言而喻的，無論是后臺前臺，統(tǒng)一的代碼規(guī)范是必須的。1.一律使用小字字母2.盡量使用ShortHand形式,在font,margin,padding,background中3.處理父子關系的節(jié)點時，使用 .parent-child-grandson（大多時候parent名稱與具體業(yè)務的模塊名稱相關） 寫法 ，而不使用 .parent .child .grandson，事實證明后者在在團隊開發(fā)中更容易造成模塊間的樣式覆蓋，同時也更不易于閱讀。一個簡單的例子：在模塊一中有一列表，用第二種寫法大致如下：.informationlist{}.informationlist .listitem{}而同時，在模塊二中也存在一列表，開發(fā)者正好也用到了.listitem，而且認為這個命名不常見，前面沒有加上限定，直接使用了.listitem ，這樣就極容易造成了樣式?jīng)_突。或許您提出不同意見：我們強制讓所有的樣式前面都加一個關于其模塊名的限定，把模塊二中的.listitem改成 .module2 .listitem，不就ok了？但這樣并不好，因為在實際應用中，不能要求所有的樣式寫法一定要加上模塊限定，比如在body節(jié)點下的某個浮動節(jié)點，我們就不能這樣處理。同時，針對第一種寫法，我們還可以很輕松開發(fā)出一個CSS的檢測軟件，用來檢測語法，判斷覆蓋。（我們知道判斷出.a .b, .a>b,.b的覆蓋關系遠比.a-b復雜的多）
更多信息請查看IT技術專欄
公眾號
事業(yè)單位
當前位置：
公考類
招聘類
各類考試