最近看到N多介紹CSS框架，前些天我說過一句話：“在我有限的視野里，還沒見到可以真正可以稱得上css框架的東東~”，當(dāng)然也可能是我的視野太小了，或者是說世界太大了，我自己還是感覺還有一大堆我看不到的東西。

先來看一下一個(gè)我比較認(rèn)同的概念：

框架可分為白盒(White-Box)與黑盒(Black-Box)兩種框架。

基于繼承的框架被稱為白盒框架。所謂白盒即具備可視性，被繼承的父類的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)對(duì)子類而言都是可知的。利用白盒框架的應(yīng)用開發(fā)者通過衍生子類或重寫父類的成員方法來開發(fā)系統(tǒng)。子類的實(shí)現(xiàn)很大程度上依賴于父類的實(shí)現(xiàn)，這種依賴性限制了重用的靈活性和完全性。但解決這種局限性的方法可以是只繼承抽象父類，因?yàn)槌橄箢惢旧喜惶峁┚唧w的實(shí)現(xiàn)。白盒框架是一個(gè)程序骨架，而用戶衍生出的子類是這個(gè)骨架上的附屬品。

基于對(duì)象構(gòu)件組裝的框架就是黑盒框架。應(yīng)用開發(fā)者通過整理、組裝對(duì)象來獲得系統(tǒng)的實(shí)現(xiàn)。用戶只須了解構(gòu)件的外部接口，無須了解內(nèi)部的具體實(shí)現(xiàn)。另外，組裝比繼承更為靈活，它能動(dòng)態(tài)地改變，繼承只是一個(gè)靜態(tài)編譯時(shí)的概念。

在理想情況下，任何所需的功能都可通過組裝已有的構(gòu)件得到，事實(shí)上可獲得的構(gòu)件遠(yuǎn)遠(yuǎn)不能滿足需求，有時(shí)通過繼承獲得新的構(gòu)件比利用已有構(gòu)件組裝新構(gòu)件更容易，因此白盒和黑盒將同時(shí)應(yīng)用于系統(tǒng)的開發(fā)中。不過白盒框架趨向于向黑盒框架發(fā)展，黑盒框架也是系統(tǒng)開發(fā)希望達(dá)到的理想目標(biāo)。

再回頭看一下現(xiàn)在網(wǎng)上那樣多CSS框架（YUI是叫“YUI Library CSS Tools” 并非是“YUI CSS Frameworks”），有多少是真正以框架的概念在寫，有多少只是定義樣式基類的。當(dāng)然，每個(gè)人對(duì)框架的理解不一定，你可能不認(rèn)同我的說法。

再談一下CSS 框架，并不非我不認(rèn)可這個(gè)東西的存在，我從一兩年前也就一直在嘗試這樣的東西。對(duì)于大型網(wǎng)站，前端的開發(fā)需要一個(gè)解決方案。框架自然是首選的?？上Ь嚯x我太遠(yuǎn)了，我太弱了T_T，我只要要求兩點(diǎn)：

管理下面的內(nèi)容的東西
類/組件
很明顯，第一點(diǎn)，CSS做不到，第二點(diǎn)，相對(duì)其它語言很弱的說。

大約在一年前做一個(gè)中型網(wǎng)站時(shí)，我為了偷懶，我想到內(nèi)容模塊化，讓程序員拼頁面。大約方向也就是封裝了一個(gè)又一個(gè)的功能塊，程序員在要用到哪一塊內(nèi)容時(shí)就只要使用相應(yīng)的HTML與CSS，大家都方便，我不要拼頁面，他不用重復(fù)套代碼，大家好才是真的好。

在同一個(gè)網(wǎng)站，差不多的內(nèi)容塊，多次使用是很正常的事，這也是就讓模塊化成為可能，比如一個(gè)圖片列表，可能是用戶頭像列表，或者群組的圖標(biāo)列表，這時(shí)你會(huì)怎樣寫呢？相同的用這樣嗎？

.photoListUesr,.photoListGroup{ /*_*/ }

這樣不是說不行，但如果突然說要再加一個(gè)相似的呢？這時(shí)可能就要調(diào)整樣式。而我呢？嘗試過這樣的使用方式：

<div class="photoList UesrCt" />
<div class="photoList GroupCt" />

這樣的話，我們一開始就分離出共同表現(xiàn)的東西，把.photoList當(dāng)成原型，通處額外的class再去處理細(xì)節(jié)。前些天，我寫了 面向?qū)ο蟮腦HTML與CSS編程 ，其實(shí)只寫了一半，另一半是詳細(xì)的例子，不過介于要做太多的例子跟核心已經(jīng)寫出來就沒寫完，^^ 當(dāng)然，這樣也存在一定的問題，就是最初的原型的定義要很慎重，要盡量做到以后就算是改版也可能不用修改。CSS這東西，基本上一個(gè)框架最多只能適合一個(gè)站，當(dāng)然，如果這個(gè)站足夠大的話，這樣使用才是有意義滴。

HTML與CSS越是模塊化，文件越分散這個(gè)問題就越嚴(yán)重。HTML倒是好辦，反正是應(yīng)用程序最終要合并輸出一份，但CSS一般會(huì)給拋棄直接使用。如果在剛才的例子中，在網(wǎng)頁導(dǎo)入CSS的方式是這樣的話：

@import url(/xxx/photoList.css);
@import url(/xxx/UserCt.css);
@import url(/xxx/GroupCt.css);

那甚至可以考慮用程序來拼頁面，但是使用方便，請(qǐng)求數(shù)也成正比，一般情況大家都會(huì)選擇手動(dòng)合并文件。雖然人腦比電腦更智能，但很多時(shí)候，人腦的計(jì)算能力是比不上電腦滴。我曾經(jīng)有這樣的想法，就是使用服務(wù)端程序來處理CSS的發(fā)布機(jī)制，大約方向就是通過網(wǎng)站訪問日志來分析出整個(gè)站各種頁面的使用量，通過程序來計(jì)算哪些公共使用的要合并，合并的順序（CSS的文件順序會(huì)影響到優(yōu)先權(quán)），等等各種計(jì)算并壓縮輸出。

可惜的是，這樣一套復(fù)雜的程序可能只適合一個(gè)站，或者同系列的站群。雖然說做起來有點(diǎn)折騰，但我相信門戶級(jí)別網(wǎng)站使用這樣的方式是有必要滴，當(dāng)然前提還要整個(gè)團(tuán)隊(duì)都要使用相同的設(shè)計(jì)模式。

PS:以上CSS發(fā)布程序，只是我的幻想，還沒嘗試過，有興趣的朋友可以嘗試一下，如有意外，概不負(fù)責(zé)。

當(dāng)然，就以上這些還是不能稱得上CSS Frameworks，或許只能叫成一個(gè)系統(tǒng)級(jí)解決方案，畢竟，CSS只是描述性語言。

前晚跟月影一起吃烤鴨時(shí)，有聊到這個(gè)，他問我有沒有前端一體化的解決方案。JS組件化時(shí)也會(huì)面臨同樣的問題，差不多的發(fā)布機(jī)制應(yīng)該也可以適用JS。不過完全的一體化解決方案我還沒想好，也許月影多請(qǐng)我吃幾次烤鴨我就能想好

• css
• Frameworks