一、引言
本文的核心觀點為CSS的合并與模塊化，似乎與前一篇文章“CSS樣式的再分離”有矛盾，其實不然，分離可以精簡CSS代碼，合并也可以精簡CSS代碼，一切都是權(quán)衡！或是說是在恰當(dāng)?shù)那闆r下使用恰當(dāng)?shù)氖侄巍?br />正如前文所提到的，分離可以精簡CSS，但是同時會帶來巨大的HTML代碼的開銷，顯然，對所有的樣式進行再分離式不切實際的，是會帶來痛苦的。前文提到的“通用庫”看似屬于分離，其實又是分離之外的東西。“通用庫”屬于很良性的東西，任何網(wǎng)站都可以拿來用，不會產(chǎn)生什么副作用，因為其與當(dāng)前項目的結(jié)構(gòu)，樣式表現(xiàn)沒有必然的關(guān)聯(lián)。“通用庫”就像是一個公共資源，大家都可以來采擷。但是“實際項目庫”卻是個燙手的山芋，這是根據(jù)當(dāng)前實際項目分離出來的獨立樣式集合，我們可能會分理出頁面中常見的背景色樣式（如background-color:#f7f7f7;），可那會分理出特定的粗邊框樣式（如border:3px solid #c80000;），一般情況下，這是很ok的，但是，如果一些模塊化的樣式（例如整站通用的按鈕）也是使用的分離樣式組合而成，那么，后期要是修改按鈕樣式，就會很痛苦，因為會有那么多的樣式要替換。
所以，盲目的分離是會帶來惡果的。

本文的“合并”和“分離”屬于對立又相輔相成的，理解的“合并”與“分離”的精髓之后，您會發(fā)現(xiàn)寫CSS代碼就是一門藝術(shù)。同樣的，本文也是為我后面的“我的CSS架構(gòu)”一文做鋪墊的，寫這些都是為了同一個目的：寫出最精簡高效的CSS代碼。

二、明確“模塊化”專指“頁面元素的模塊化”
首先您要明確，樣式再分離是應(yīng)用到“模塊化的獨立元素”上可那會產(chǎn)生后期維護的問題，并不是應(yīng)用到“頁面模塊”會產(chǎn)生后期維護的問題。例如，我們將很多分離的樣式嵌入到一個整站通用的的“評論模塊”中，是不會產(chǎn)生任何所謂的后期維護的問題的，除非您網(wǎng)站的評論并不是個“模塊”，而是這里一段評論的HTML代碼，那里又是另外一評論的HTML代碼，有經(jīng)驗的開發(fā)人員都應(yīng)該清楚我想要表達的意思。

本文標題所說的“模塊化”指的是頁面元素，例如網(wǎng)站通用按鈕，通用選項卡，通用小圖標，或是頁面的一些固定框架結(jié)構(gòu)等。這些元素是不適宜使用樣式再分離的（或者說僅僅使用樣式再分離）。

三、什么是CSS樣式合并
何為CSS樣式合并，所謂CSS樣式合并，指的是一些不可分離的樣式（按鈕，圖標等），將他們公共的樣式部分進行合并，非公共的再次獨立出來，以減小CSS文件的大小。我想，合并的做法很多同行都做過，可能不是很徹底，或是系統(tǒng)。很多時候，我們知道合并的好處，但是往往由于各種原因，沒有從整體對樣式進行設(shè)計與架構(gòu)，造成樣式合并的效果基本上沒有發(fā)揮出來。下面我舉個實例，會讓您對樣式合并有一個更進一步的認識。此實例來自淘寶首頁，其對背景圖片的樣式合并。

我們使用小bug（我對firebug的昵稱）隨便看一個帶背景圖片的元素，例如下面這個（免費注冊按鈕）：

此時firebug右側(cè)顯示的內(nèi)容截圖如下：

其對所有使用到這張sprite背景圖的樣式進行了合并，試想下，淘寶的背景圖片地址這么長，加入這些樣式不合并，那么首頁的CSS大小增加的量可能要上K了，對于淘寶首頁這樣大流量的的頁面來說，增加1K的大小，就是要從馬云手中拿走成百上萬的money~~
就我自己而言，使用最多的合并也是背景圖片的合并。其次就是一些效果類似但又不完全一致的模塊化元素。樣式的合并，沒有規(guī)律性可言，一般，遇到結(jié)構(gòu)或是寫法類似但又不完全一樣的元素的時候，就可以使用樣式的合并。

使用英文字符的逗號(,)分隔樣式名，將相同的樣式寫在后面，這也些類似于初中數(shù)學(xué)里的“合并同類項”。項目不同，情況也各異，要想達到充分的樣式合并，前期的設(shè)計與架構(gòu)很重要。

四、CSS分離與CSS合并的共存
CSS“通用庫”游離于三界之外，不參與這類紛爭（例如與其他元素合并）。這里的CSS分離指的就是在實際項目中分離出來的“實際項目庫”。一般情況下，“分離”與“合并”處于CSS文件的不同部分，兩者是不搭噶的。“分離”一般針對那些非模塊化的元素，而“合并”多針對模塊化的元素，所以兩者是對立的屬于不同類別的，之間不會產(chǎn)生什么沖突。由于兩者都有精簡CSS代碼的作用，所以雙管齊下，事半功倍。

雖說“井水不犯河水，雞腿有別鴨腿”，但是河水泛濫，家禽玩蛋之時，兩者也會產(chǎn)生交集的。“分離”與“合并”也是如此。這不是一句話能夠說清楚的，帶我娓娓道來。
前面提到，模塊化元素是不適宜使用分離的。比說如，文本框，設(shè)計師們往往喜歡在文本框上打主意，例如添加個淡灰漸變背景什么的，例如下面的效果（為截圖）：

這里的文本框就是整站通用的獨立的“模塊化元素”，是不推薦使用分離的?？偣舱麄€網(wǎng)站，文本框的寬度有好幾種，從寬度50像素左右的，200像素左右的，到450像素左右的都會有，我們不可能針對每個寬度寫一個獨立的樣式的。顯然，這里需要對文本框樣式進行合并，將公共的部分獨立出來，于是，我們可能會有如下的代碼（其中inset的背景與其他背景圖片元素進行合并了，所以這里只有background-position屬性）：

好的，以上就是inset的公共樣式，看上去像是分離，其實是合并。現(xiàn)在唯一落下的就是寬度屬性了，這里寬度屬性為單一的屬性，我們是不是可以用“樣式分離”的意識將其分離出來，與其他元素公用呢，就像下面：


然后使用input時，HTML代碼如下：


同時，分離出來的w163又能被頁面其他地方的元素重用，豈不是很好。好嗎？一點都不好！記住，模塊化的元素千萬不能用“分離”的思想來處理！我們試想一下，要是項目全部完成了，主管說：“這個文本框?qū)挾扔悬c長，你給我改短一點”，試問，您要怎么改？w163本身就已經(jīng)分離并語義明確化，就算你class名不變，修改后面的163px為140px，確實，所有的應(yīng)用w163樣式的文本框?qū)挾葴p小了，但是，項目上其他應(yīng)用了w163樣式的元素就遭殃了，這就是我提到的“痛苦”。避免以后產(chǎn)生痛苦，一定要技術(shù)這里原則：模塊化元素不分離！

所以，這里的意識不能停在“分離”上，“分離”還是“不分離”主要體現(xiàn)在命名上，“分離”思想下的命名只針對屬性本身，猶如機器般，是沒有情感的，“無分離”思想的命名是針對頁面內(nèi)容，命名可以反映其所知道的大體內(nèi)容，有血有肉的，所以，上述文本框的寬度可以使用類似下面的命名方式：


使用使應(yīng)該如下html代碼：


雖然txtw1也是分離出來的單樣式，但是由于其命名帶有內(nèi)容語義，所以，不會被貿(mào)然當(dāng)作分離樣式在其他地方適應(yīng)，而帶來后期維護潛在的問題。

還沒完，其實上面都是講的“非分離”，不是講“共存”，似乎有點不切題。不急，下面才是關(guān)鍵。這里，txtw1明明是獨立樣式，卻不能當(dāng)作分離樣式使用，這種心情復(fù)雜——可惜了！實則不然，這里txtw1的樣式是可以當(dāng)作“分離”樣式使用的，如何使用？關(guān)鍵就是本節(jié)的關(guān)鍵字“合并”。我們可以將分離樣式與內(nèi)容語義的獨立樣式進行合并，就可以實現(xiàn)樣式分離重用又沒有后期維護潛在風(fēng)險的問題。比方說，我在做一個列表，這個列表的寬度就是163像素，嘿，正好，CSS中有個寬度為163像素的獨立樣式txtw1，但是這個到嘴的肥鴨卻吃不得（前面提到的潛在風(fēng)險），怎么辦，我們可以分離出一個163像素寬度的樣式w163，同時與txtw1進行合并，這樣，就實現(xiàn)了樣式重用，又規(guī)避了潛在風(fēng)險，于是，我們會有如下的樣式代碼：


這就是“分離”與“合并”共存的極佳實例。
要注意，只有頁面要使用到與文本框獨立寬度一樣寬度的時候才進行分離并合并，所以以下做法是屬于犯傻不可取的：


現(xiàn)在，我們要修改txtw1樣式下的文本框?qū)挾葹?50像素，您直接改就行了，只有文本框應(yīng)用了這個樣式，不會有潛在問題。但是，記得，這里的合并要還原，如下：


可見，真正理解了“合并”與“分離”，就不會出現(xiàn)什么維護上的風(fēng)險，相反，可以最大限度的發(fā)揮兩者共有的精簡CSS的特性，相輔相成。

五、精簡高效的CSS代碼是通力合作的結(jié)果
就算你CSS再牛叉，理解再深刻，沒有設(shè)計師以及后臺程序工程師的配合，您的CSS代碼會不得不變得不高效，甚至難以維護。
關(guān)于設(shè)計師的作用，我在前文已經(jīng)提到，這里不再多說。關(guān)于后臺程序員，這里簡單說下。樣式再分離，最怕的就是整站通用的模塊化元素。如果網(wǎng)站系統(tǒng)架構(gòu)良好，凡事功能一致的模塊都是僅僅一段代碼，或是一個頁面片段，整站通用的，此時，“樣式再分離”的優(yōu)勢和潛力可謂發(fā)揮到了極致，分離樣式可以很放心的重用，很放心的分離（通用單元素和復(fù)雜結(jié)構(gòu)除外），因為即使后期修改，也只會改一個地方，分離所帶來的多點維護的問題就無從談起，分離只有百益而無一弊。但是，要是碰到“散槍法”的后臺程序員，沒有模塊化的思想，系統(tǒng)沒有良好的架構(gòu)，類似功能遍地開花，啊哦！my lady gaga！我實在不敢想像此時應(yīng)用樣式分離那種餓殍遍野的慘況。

波音747的馬達裝載拖拉機上是不頂鳥用的。“分離”+“合并”的高效CSS代碼是需要設(shè)計師，前端開發(fā)工程師，后臺開發(fā)工程師都很專業(yè)的情況下才能發(fā)揮巨大效用的，如果不是這種情況，我建議還是沿著主流CSS的路子走，否則會有苦頭吃的。

六、結(jié)語
一些個人觀點，可能與您認識相左，歡迎交流。要是有您認為表述不準確的地方，也歡迎指正。
就這些。