组建合理DIV+CSS网页框架

148月

组建合理DIV+CSS网页框架

CSS越来越成为网页搭建的主流，各企业与IT公司对CSS也越来越重视。然而依赖css越多，样式表文件就会变得越大越复杂。与此同时，文件维护和组织的考验也随之而来。曾几何时只要一个CSS文件就够了——所有规则（rule）汇聚一堂，增删改都很方便——可这种日子早已远去。现在构建网站时，必须花点时间好好筹划，如何组织规划，构建合理高效的CSS系统。

　　首先从文件的组织开始，构建css系统的第一步是大纲的拟定。css组织规划的重要性堪比网站目录结构。没有哪种方案放之四海而皆准，因此我们会讨论一些基本的组织方案，以及它们各自的利弊。你需要根据你开发项目的特点进行思考，以确实最终的方案。

　　通常可以使用一个主CSS文件，来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉页脚和其他相同模块等样式。有了主CSS文件之后，我们开始探讨更高级CSS组织策略。

一、基于原型
　　最基本的策略是基于原型页面（archetype page）分离CSS文件。假如一个网站的首页、子页面和组合页设计不同，就可以采用基于原型的策略。这种策略下每个页面都会有专属的CSS文件。
　　在原型数量不多的情况下，这个方法简单明了、行之有效。然而，当页面元素并不按部就班的位于各个原型页时，问题就出现了。如果子页面和组合页共享某些元素，而首页却没有，我们应该怎么做呢?
　　把共享元素放入主CSS文件。这虽不是最纯正的解决办法，却适用于某些具体情况。可是如果网站庞大，（这样做的话）主CSS文件会迅速膨胀——这就违背了分离文件的初衷:避免导入不必要的大文件。
　　在组合页和子页面的CSS文件里各放一份样式代码。这么做就意味着要维护冗余代码，很显然我们不想这样。
　　创建一个新的文件，由这两种页面共享。这听起来不错。不过假如只有10行代码，我们创建这个文件仅仅是为了共享这10行代码？这方法很纯粹，但如果网站庞大有很多对页面共享很少量元素时就显得很笨重了。
　　创建一个单独的CSS文件，包含所有共享元素的样式。这方法可能比较简单，却要取决于网站的大小和共享元素的多少。有种情况会很烦:导入了一个很大的CSS文件，但页面只用到一小部分样式——还是那句话，这违背了分离文件的初衷。
　　这就是我所说的重叠的两难（overlap dilemma）。零碎css规则的重叠不一而足，并没有一个完全清晰无误的方案来组织它们。

二、基于页面元素、模块
　　如果网站使用服务器端include，这个方法会很不错。举例说明，如果使用页眉include，它会有自己相应的CSS文件。页脚或者其他部分的include可以如法炮制，只须导入自己的CSS文件。这个方法简单干净，不过可能会产生很多小CSS文件。
　　举例来说，假如页脚的样式只需要20行css代码，单独创建一个文件就划不来了。而且这个方法会导致每个页面都包含一堆CSS文件——因为有多少include，就得有多少CSS文件。

三、基于标记
　　这个方案直观实际，与前一个类似。如果网站共有30个页面，其中10个含有form，那么可以创建一个CSS文件专门处理form的样式，只在这10个页面导入它。如果另外10个页面含有table，就创建一个文件专门处理table样式……诸如此类。

四、其他CSS组织技巧
　　除了用主观的方法组织文件，我们还要考虑如打印、手持设备和屏幕等多种媒体类型。这虽然已经很清楚的定义过，可依旧是建立文件结构时应该考虑的一个因素。一旦必须支持多种媒体类型，主CSS文件里的某些规则可能就得重新考虑。另外，品牌联合也可能是一个重要因素。如果涉及品牌联合，你就得考虑哪些元素应该调整以适应另一品牌。比如分别使用不同的CSS文件等。
　　还有一个常被忽略的技巧:使用嵌套的@import语句。只包含一连串@import语句，或者再加几句css规则，就能创建一个CSS文件。用这个方法完全可以创建网站的主CSS文件（用@import导入各部分的样式文件）。假如网站的每个页面都导入了4到5个不同的CSS文件，无疑你应该考虑使用这个技巧。

规范的DIV+CSS英文网站建设请访问www.onlygrape.com