|
最近看到N多介紹CSS框架，前些天我說過一句話：“在我有限的視野里，還沒見到可以真正可以稱得上css框架的東東~”，當(dāng)然也可能是我的視野太小了，或者是說世界太大了，我自己還是感覺還有一大堆我看不到的東西。
先來看一下一個我比較認(rèn)同的概念：
框架可分為白盒(White-Box)與黑盒(Black-Box)兩種框架。
基于繼承的框架被稱為白盒框架。所謂白盒即具備可視性，被繼承的父類的內(nèi)部實現(xiàn)細(xì)節(jié)對子類而言都是可知的。利用白盒框架的應(yīng)用開發(fā)者通過衍生子類或重寫父類的成員方法來開發(fā)系統(tǒng)。子類的實現(xiàn)很大程度上依賴于父類的實現(xiàn)，這種依賴性限制了重用的靈活性和完全性。但解決這種局限性的方法可以是只繼承抽象父類，因為抽象類基本上不提供具體的實現(xiàn)。白盒框架是一個程序骨架，而用戶衍生出的子類是這個骨架上的附屬品。
基于對象構(gòu)件組裝的框架就是黑盒框架。應(yīng)用開發(fā)者通過整理、組裝對象來獲得系統(tǒng)的實現(xiàn)。用戶只須了解構(gòu)件的外部接口，無須了解內(nèi)部的具體實現(xiàn)。另外，組裝比繼承更為靈活，它能動態(tài)地改變，繼承只是一個靜態(tài)編譯時的概念。
在理想情況下，任何所需的功能都可通過組裝已有的構(gòu)件得到，事實上可獲得的構(gòu)件遠(yuǎn)遠(yuǎn)不能滿足需求，有時通過繼承獲得新的構(gòu)件比利用已有構(gòu)件組裝新構(gòu)件更容易，因此白盒和黑盒將同時應(yīng)用于系統(tǒng)的開發(fā)中。不過白盒框架趨向于向黑盒框架發(fā)展，黑盒框架也是系統(tǒng)開發(fā)希望達到的理想目標(biāo)。
再回頭看一下現(xiàn)在網(wǎng)上那樣多CSS框架（YUI是叫“YUI Library CSS Tools” 并非是“YUI CSS Frameworks”），有多少是真正以框架的概念在寫，有多少只是定義樣式基類的。當(dāng)然，每個人對框架的理解不一定，你可能不認(rèn)同我的說法。
再談一下CSS 框架，并不非我不認(rèn)可這個東西的存在，我從一兩年前也就一直在嘗試這樣的東西。對于大型網(wǎng)站，前端的開發(fā)需要一個解決方案�？蚣茏匀皇鞘走x的�？上Ь嚯x我太遠(yuǎn)了，我太弱了T_T，我只要要求兩點：
很明顯，第一點，CSS做不到，第二點，相對其它語言很弱的說。
大約在一年前做一個中型網(wǎng)站時，我為了偷懶，我想到內(nèi)容模塊化，讓程序員拼頁面。大約方向也就是封裝了一個又一個的功能塊，程序員在要用到哪一塊內(nèi)容時就只要使用相應(yīng)的HTML與CSS，大家都方便，我不要拼頁面，他不用重復(fù)套代碼，大家好才是真的好。
在同一個網(wǎng)站，差不多的內(nèi)容塊，多次使用是很正常的事，這也是就讓模塊化成為可能，比如一個圖片列表，可能是用戶頭像列表，或者群組的圖標(biāo)列表，這時你會怎樣寫呢？相同的用這樣嗎？
.photoListUesr,.photoListGroup{ /*_*/ }
這樣不是說不行，但如果突然說要再加一個相似的呢？這時可能就要調(diào)整樣式。而我呢？嘗試過這樣的使用方式：
<div class="photoList UesrCt" />
<div class="photoList GroupCt" />
這樣的話，我們一開始就分離出共同表現(xiàn)的東西，把.photoList當(dāng)成原型，通處額外的class再去處理細(xì)節(jié)。前些天，我寫了 面向?qū)ο蟮腦HTML與CSS編程 ，其實只寫了一半，另一半是詳細(xì)的例子，不過介于要做太多的例子跟核心已經(jīng)寫出來就沒寫完，^^ 當(dāng)然，這樣也存在一定的問題，就是最初的原型的定義要很慎重，要盡量做到以后就算是改版也可能不用修改。CSS這東西，基本上一個框架最多只能適合一個站，當(dāng)然，如果這個站足夠大的話，這樣使用才是有意義滴。
HTML與CSS越是模塊化，文件越分散這個問題就越嚴(yán)重。HTML倒是好辦，反正是應(yīng)用程序最終要合并輸出一份，但CSS一般會給拋棄直接使用。如果在剛才的例子中，在網(wǎng)頁導(dǎo)入CSS的方式是這樣的話：
@import url(/xxx/photoList.css);
@import url(/xxx/UserCt.css);
@import url(/xxx/GroupCt.css);
那甚至可以考慮用程序來拼頁面，但是使用方便，請求數(shù)也成正比，一般情況大家都會選擇手動合并文件。雖然人腦比電腦更智能，但很多時候，人腦的計算能力是比不上電腦滴。我曾經(jīng)有這樣的想法，就是使用服務(wù)端程序來處理CSS的發(fā)布機制，大約方向就是通過網(wǎng)站訪問日志來分析出整個站各種頁面的使用量，通過程序來計算哪些公共使用的要合并，合并的順序（CSS的文件順序會影響到優(yōu)先權(quán)），等等各種計算并壓縮輸出。
可惜的是，這樣一套復(fù)雜的程序可能只適合一個站，或者同系列的站群。雖然說做起來有點折騰，但我相信門戶級別網(wǎng)站使用這樣的方式是有必要滴，當(dāng)然前提還要整個團隊都要使用相同的設(shè)計模式。
PS:以上CSS發(fā)布程序，只是我的幻想，還沒嘗試過，有興趣的朋友可以嘗試一下，如有意外，概不負(fù)責(zé)。
當(dāng)然，就以上這些還是不能稱得上CSS Frameworks，或許只能叫成一個系統(tǒng)級解決方案，畢竟，CSS只是描述性語言。
前晚跟月影一起吃烤鴨時，有聊到這個，他問我有沒有前端一體化的解決方案。JS組件化時也會面臨同樣的問題，差不多的發(fā)布機制應(yīng)該也可以適用JS。不過完全的一體化解決方案我還沒想好，也許月影多請我吃幾次烤鴨我就能想好。
本文鏈接：http://www.95time.cn/tech/web/2008/5639.asp 
出處：藍(lán)色理想
責(zé)任編輯：bluehearts
◎進入論壇網(wǎng)頁制作、WEB標(biāo)準(zhǔn)化版塊參加討論，我還想發(fā)表評論。
|
