先来看一下一个我比较认同的概念：

框架可分为白盒(White-Box)与黑盒(Black-Box)两种框架。

基于继承的框架被称为白盒框架。所谓白盒即具备可视性，被继承的父类的内部实现细节对子类而言都是可知的。利用白盒框架的应用开发者通过衍生子类或重写父类的成员方法来开发系统。子类的实现很大程度上依赖于父类的实现，这种依赖性限制了重用的灵活性和完全性。但解决这种局限性的方法可以是只继承抽象父类，因为抽象类基本上不提供具体的实现。白盒框架是一个程序骨架，而用户衍生出的子类是这个骨架上的附属品。

基于对象构件组装的框架就是黑盒框架。应用开发者通过整理、组装对象来获得系统的实现。用户只须了解构件的外部接口，无须了解内部的具体实现。另外，组装比继承更为灵活，它能动态地改变，继承只是一个静态编译时的概念。

在理想情况下，任何所需的功能都可通过组装已有的构件得到，事实上可获得的构件远远不能满足需求，有时通过继承获得新的构件比利用已有构件组装新构件更容易，因此白盒和黑盒将同时应用于系统的开发中。不过白盒框架趋向于向黑盒框架发展，黑盒框架也是系统开发希望达到的理想目标。

再回头看一下现在网上那样多CSS框架（YUI是叫“YUI Library CSS Tools” 并非是“YUI CSS Frameworks”），有多少是真正以框架的概念在写，有多少只是定义样式基类的。当然，每个人对框架的理解不一定，你可能不认同我的说法。

再谈一下CSS 框架，并不非我不认可这个东西的存在，我从一两年前也就一直在尝试这样的东西。对于大型网站，前端的开发需要一个解决方案。框架自然是首选的。可惜距离我太远了，我太弱了T_T，我只要要求两点：

• 管理下面的内容的东西
• 类/组件

很明显，第一点，CSS做不到，第二点，相对其它语言很弱的说。

大约在一年前做一个中型网站时，我为了偷懒，我想到内容模块化，让程序员拼页面。大约方向也就是封装了一个又一个的功能块，程序员在要用到哪一块内容时就只要使用相应的HTML与CSS，大家都方便，我不要拼页面，他不用重复套代码，大家好才是真的好。

在同一个网站，差不多的内容块，多次使用是很正常的事，这也是就让模块化成为可能，比如一个图片列表，可能是用户头像列表，或者群组的图标列表，这时你会怎样写呢？相同的用这样吗？

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

这样不是说不行，但如果突然说要再加一个相似的呢？这时可能就要调整样式。而我呢？尝试过这样的使用方式：

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

这样的话，我们一开始就分离出共同表现的东西，把.photoList当成原型，通处额外的class再去处理细节。前些天，我写了面向对象的XHTML与CSS编程，其实只写了一半，另一半是详细的例子，不过介于要做太多的例子跟核心已经写出来就没写完，^^ 当然，这样也存在一定的问题，就是最初的原型的定义要很慎重，要尽量做到以后就算是改版也可能不用修改。CSS这东西，基本上一个框架最多只能适合一个站，当然，如果这个站足够大的话，这样使用才是有意义滴。

HTML与CSS越是模块化，文件越分散这个问题就越严重。HTML倒是好办，反正是应用程序最终要合并输出一份，但CSS一般会给抛弃直接使用。如果在刚才的例子中，在网页导入CSS的方式是这样的话：

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

那甚至可以考虑用程序来拼页面，但是使用方便，请求数也成正比，一般情况大家都会选择手动合并文件。虽然人脑比电脑更智能，但很多时候，人脑的计算能力是比不上电脑滴。我曾经有这样的想法，就是使用服务端程序来处理CSS的发布机制，大约方向就是通过网站访问日志来分析出整个站各种页面的使用量，通过程序来计算哪些公共使用的要合并，合并的顺序（CSS的文件顺序会影响到优先权），等等各种计算并压缩输出。

可惜的是，这样一套复杂的程序可能只适合一个站，或者同系列的站群。虽然说做起来有点折腾，但我相信门户级别网站使用这样的方式是有必要滴，当然前提还要整个团队都要使用相同的设计模式。

PS:以上CSS发布程序，只是我的幻想，还没尝试过，有兴趣的朋友可以尝试一下，如有意外，概不负责。^_^~

当然，就以上这些还是不能称得上CSS Frameworks，或许只能叫成一个系统级解决方案，毕竟，CSS只是描述性语言。

前晚跟月影一起吃烤鸭时，有聊到这个，他问我有没有前端一体化的解决方案。JS组件化时也会面临同样的问题，差不多的发布机制应该也可以适用JS。不过完全的一体化解决方案我还没想好，也许月影多请我吃几次烤鸭我就能想好。

广告一下：Ucren-widgets，国内一个不错的JS组件。

扩展阅读：CSS Frameworks + CSS Reset: Design From Scratch

推荐本书：《Web标准设计》

那要怎样OO呢？现在大家都知道CSS是可以介样写滴：

.G_G { /* xxxxxx */ }

我们可以把它大约看一个原型，或者说成类，-__-b 好像本来就是类的样子，然后要在HTML里“实例化”一个对象，例如：

<div class="G_G">笨蛋嗷嗷</div>

该元素会使用上CSS相应的定义，但仅仅对应的class还是不够的，因为我们页面可能会多处应用到这个class，为了处理好“私有”的关系，把刚才的代码改成：

<div id="aoao" class="G_G">笨蛋嗷嗷</div>

这样的话，这个ID为aoao的元素就会应用.G_G这个类的定义，而且可以用#aoao{}这样的选择符来进去私有效果的定义，这样也不会影响到公共用的.G_G这个类，同时，#aoao定义的优先权会比.G_G高，符合私有定义比公共定义优先高的常理^^。

由于我使用了ID这个具有唯一性的东东，对这种私有定义后的东西复用就成了问题（一个ID只能在一个页面上出现一次，不知道谁说的，反正是真理）。如果我们要实现多个相同私有化的东东怎办呢？那我们就必须来实现“多态”。挖哈哈。再改一下代码：

<div class="G_G o_O">笨蛋嗷嗷</div>

一个是“G_G”，另一个是“o_O”，但是我们如果使用上.o_O{}也是可以定义到元素，假如CSS是这样的话：

.G_G {width:100%}
.o_O {color:#123456}

元素将都被定义到，而且由于定义不层叠，都会给应用。再假如代码是这样的话，不知道会不会更好理解。

<div class="layout color">不是笨蛋嗷嗷鸟</div>

.layout{width:100%}
.color{color:#123456}

接着，要来实现“封装”。子级选择符大家应该常常用吧，换代码：

<div class="G_G"><span class="bendan">笨蛋</span>嗷嗷</div>

虽然.bendan{}跟.G_G .bendan{}都可以定义，但是后者只能应用在class为“G_G”的元素，我们可以简单把.bendan{}理解成全局定义，把.G_G .bendan{}理解成局部定义，这样的话就有利于我们XHTML与CSS的模块化。^^传说中的“封装”出现了，再接着。

<div id="aoao" class="G_G o_O"><span class="bendan">笨蛋</span>嗷嗷</div>

这样的代码就可以产生无数的变化了，还不明白的从头看起。^^

其实，这些跟真正的面向对象还有很大一段距离，我只是在学标题党，不过可以用它来理解ID与class的应用。

推荐本书：《Web标准设计》

打个比方，当你拿到一本未看过的书时，理论上你会翻翻目录、翻翻前言，通过目录寻找感兴趣的内容，或者从头翻起。那博客呢？当你来到一个未访问过的博客时，也许你会翻翻导航、翻翻关于，通过导航寻找感兴趣的内容，或者从头看起。^^是不是有点像呢？假如你知道书的某一页有感兴趣的内容，你可能就直接翻到第N页，有点像网站url一样的功能。你可能给书的某一页折角或者夹书签，是不是有点像收藏夹的功能^^，书的内容可能存在引用，指向另一本呢，是不是有点像博客文章里有个引用指向另一个网站呢?

但在大多时候，新网站的发现时，你可能是通过url访问网站某一部分的内容，而新书的发现你是从头看起，获取信息的顺序不一样。事实上，网站也不是书，详细区别就不用我讲了，换回书的概念。

当你不了解一本书时，你会先翻里面某一页的内容来看吗？当然，像有人跟你说第XX页能解决你的问题你去看就明白这种情况就例外了。当你在看书的某节或者某一页内容时，你会希望翻到这一页就是先看到目录呢？我想这样的书一定不喜欢。

那网站结构呢?在网站首页时，是否应该导航优先存在于结构呢?＝。＝ 好像全世界都是这样的；那在详细内容页面，是否应该内容优先存在于结构呢？＝。＝好像大家都不是这样滴。最多在前面加上跳过导航跳过内容。。

Web标准常说的一个优势就是一个页适合多种终端访问，假如你用手持设备来访问时，结构的先后存在的优势更加明显，如果打开某一页内容时，第一屏基本是导航好还是直接看到内容好。当然，如果是首页更期望是导航。事实上，对于手持设备，我更倾向使用对应的版本（关于手持设备使用的结构等我网站的mobile结构写得差不多再跟大家讨论），适合的内容给适合的浏览器显示。

除去正常的浏览器，手持设备，还存在各种可用于访问网站的终端。比如我用手机自带的浏览器访问，我得到的USER-AGENT为空，以前有说过media=”handheld” 为手持设备添加样式，不过也不是很理想。在还没处理每个相应浏览器的版本时，一个页适合多种终端访问这种勉强的作法还是可行的。

当然，如果你认为网站只是在电脑上的浏览器显示的，不需要这样无聊的结构也是可行滴。那这样做还有什么好处呢？利于SEO ^^，搜索引擎据说比较喜欢结构前面的文字，详细内容页导航是次要滴,也是放在后面。^^悄悄说下google搜索aoao已经可以看到我的新米排到了第一页，虽然aoao不是什么关键词，当然对于搜索引擎，域名也是一种策略，不过不这里讨论。

对于这种结构，排版也是一种问题，＝。＝，还好CSS能解决这个问题。现在我的网站就使用这种结构，有兴趣的朋友关掉样式或者查看代码看一下。当然，复杂结构的网站使用这样概念来做，就有点勉强了，但办法总会是有滴，只是我还没想到，哎，技术没跟上。。也许是书架，也许是图书馆，也许什么都不是。

推荐阅读：Web内容可访问性指南1.0(WCAG 1.0)

推荐本书：《Web标准设计》