架构CSS<wbr></wbr><wbr></wbr>
在当前浏览器普遍支持的前提下,css<wbr></wbr>被我们赋予了前所未有的使命。然而依赖css<wbr></wbr>越多,样式表文件就会变得越大越复杂。与此同时,文件维护和组织的考验也随之而来。<wbr></wbr>
(<wbr></wbr>曾几何时)<wbr></wbr>只要一个css<wbr></wbr>文件就够了——所有规则(rule)<wbr></wbr>汇聚一堂,增删改都很方便——可这种日子早已远去。(<wbr></wbr>现在)<wbr></wbr>建立新网站时,必须花点时间好好筹划怎么组织和架构css<wbr></wbr>。<wbr></wbr>
<wbr></wbr>
文件的组织<wbr></wbr>
构建css<wbr></wbr>系统的第一步是大纲的拟定。(<wbr></wbr>我认为)css<wbr></wbr>组织规划的重要性堪比网站目录结构。(<wbr></wbr>注:<wbr></wbr>用词夸张一点,让你加深记忆) <wbr></wbr>没有哪种方案放之四海而皆准,因此我们会讨论一些基本的组织方案,以及它们各自的利弊。<wbr></wbr>
<wbr></wbr>
主CSS<wbr></wbr>文件<wbr></wbr>
通常可以使用一个主css<wbr></wbr>文件,来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉和其他等样式。有了主css<wbr></wbr>文件之后,我们开始探讨高级组织策略。<wbr></wbr>
<wbr></wbr>
方法一:<wbr></wbr>基于原型<wbr></wbr>
最基本的策略是基于原型页面(archetype page)<wbr></wbr>分离css<wbr></wbr>文件。假如一个网站的首页、子页面和组合页设计不同,就可以采用基于原型的策略。(<wbr></wbr>这种策略下)<wbr></wbr>每个页面都会有专属的css<wbr></wbr>文件。<wbr></wbr>
在原型数量不多的情况下,这个方法简单明了、行之有效。然而,当页面元素并不按部就班的位于各个原型页时,问题就出现了。如果子页面和组合页共享某些元素,而首页却没有,我们应该怎么做呢?<wbr></wbr><wbr></wbr>
把共享元素放入主css<wbr></wbr>文件。这虽不是最纯正的解决办法,却适用于某些具体情况。可是如果网站庞大,(<wbr></wbr>这样做的话)<wbr></wbr>主css<wbr></wbr>文件会迅速膨胀——这就违背了分离文件的初衷:<wbr></wbr>避免导入不必要的大文件。<wbr></wbr>
在组合页和子页面的css<wbr></wbr>文件里各放一份样式代码。(<wbr></wbr>这么做)<wbr></wbr>就意味着要维护冗余代码,很显然我们不想这样。<wbr></wbr>
创建一个新的文件,由这两种页面共享。这听起来不错。不过假如只有10<wbr></wbr>行代码,我们创建这个文件仅仅是为了共享这10<wbr></wbr>行代码?(<wbr></wbr>注:<wbr></wbr>杀鸡用牛刀?) <wbr></wbr>这方法很纯粹,但如果网站庞大有很多对页面共享很少量元素时(<wbr></wbr>注:<wbr></wbr>比如30<wbr></wbr>对页面分别共享10<wbr></wbr>行代码)<wbr></wbr>,就显得很笨重了。<wbr></wbr>
创建一个单独的css<wbr></wbr>文件,包含所有共享元素的样式。这方法可能比较简单,却要取决于网站的大小和共享元素的多少。有种情况会很烦:<wbr></wbr>导入了一个很大的css<wbr></wbr>文件,但页面只用到一小部分样式——还是那句话,这违背了分离文件的初衷。<wbr></wbr>
这就是我所说的重叠的两难(overlap dilemma)<wbr></wbr>。零碎css<wbr></wbr>规则的重叠不一而足,并没有一个完全清晰无误的方案来组织它们。<wbr></wbr>
<wbr></wbr>
方法二:<wbr></wbr>基于页面元素/<wbr></wbr>块<wbr></wbr>
如果网站使用服务器端include<wbr></wbr>,这个方法会很不错。举例说明,如果使用页眉include<wbr></wbr>,它会有自己相应的css<wbr></wbr>文件。页脚或者其他部分的include<wbr></wbr>可以如法炮制,只须导入自己的css<wbr></wbr>文件。这个方法简单干净,不过可能会产生很多小css<wbr></wbr>文件。<wbr></wbr>
举例来说,假如页脚的样式只需要20<wbr></wbr>行css<wbr></wbr>代码,单独创建一个文件就划不来了。而且这个方法会导致每个页面都包含一堆css<wbr></wbr>文件——因为有多少include<wbr></wbr>,就得有多少css<wbr></wbr>文件。<wbr></wbr>
<wbr></wbr>
方法三:<wbr></wbr>基于标记<wbr></wbr>
这个方案直观实际,与前一个类似。如果网站共有30<wbr></wbr>个页面,其中10<wbr></wbr>个含有form<wbr></wbr>,那么可以创建一个css<wbr></wbr>文件专门处理form<wbr></wbr>的样式,只在这10<wbr></wbr>个页面导入它。如果另外10<wbr></wbr>个页面含有table<wbr></wbr>,就创建一个文件专门处理table<wbr></wbr>样式……诸如此类。
在当前浏览器普遍支持的前提下,css<wbr></wbr>被我们赋予了前所未有的使命。然而依赖css<wbr></wbr>越多,样式表文件就会变得越大越复杂。与此同时,文件维护和组织的考验也随之而来。<wbr></wbr>
(<wbr></wbr>曾几何时)<wbr></wbr>只要一个css<wbr></wbr>文件就够了——所有规则(rule)<wbr></wbr>汇聚一堂,增删改都很方便——可这种日子早已远去。(<wbr></wbr>现在)<wbr></wbr>建立新网站时,必须花点时间好好筹划怎么组织和架构css<wbr></wbr>。<wbr></wbr>
<wbr></wbr>
文件的组织<wbr></wbr>
构建css<wbr></wbr>系统的第一步是大纲的拟定。(<wbr></wbr>我认为)css<wbr></wbr>组织规划的重要性堪比网站目录结构。(<wbr></wbr>注:<wbr></wbr>用词夸张一点,让你加深记忆) <wbr></wbr>没有哪种方案放之四海而皆准,因此我们会讨论一些基本的组织方案,以及它们各自的利弊。<wbr></wbr>
<wbr></wbr>
主CSS<wbr></wbr>文件<wbr></wbr>
通常可以使用一个主css<wbr></wbr>文件,来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉和其他等样式。有了主css<wbr></wbr>文件之后,我们开始探讨高级组织策略。<wbr></wbr>
<wbr></wbr>
方法一:<wbr></wbr>基于原型<wbr></wbr>
最基本的策略是基于原型页面(archetype page)<wbr></wbr>分离css<wbr></wbr>文件。假如一个网站的首页、子页面和组合页设计不同,就可以采用基于原型的策略。(<wbr></wbr>这种策略下)<wbr></wbr>每个页面都会有专属的css<wbr></wbr>文件。<wbr></wbr>
在原型数量不多的情况下,这个方法简单明了、行之有效。然而,当页面元素并不按部就班的位于各个原型页时,问题就出现了。如果子页面和组合页共享某些元素,而首页却没有,我们应该怎么做呢?<wbr></wbr><wbr></wbr>
把共享元素放入主css<wbr></wbr>文件。这虽不是最纯正的解决办法,却适用于某些具体情况。可是如果网站庞大,(<wbr></wbr>这样做的话)<wbr></wbr>主css<wbr></wbr>文件会迅速膨胀——这就违背了分离文件的初衷:<wbr></wbr>避免导入不必要的大文件。<wbr></wbr>
在组合页和子页面的css<wbr></wbr>文件里各放一份样式代码。(<wbr></wbr>这么做)<wbr></wbr>就意味着要维护冗余代码,很显然我们不想这样。<wbr></wbr>
创建一个新的文件,由这两种页面共享。这听起来不错。不过假如只有10<wbr></wbr>行代码,我们创建这个文件仅仅是为了共享这10<wbr></wbr>行代码?(<wbr></wbr>注:<wbr></wbr>杀鸡用牛刀?) <wbr></wbr>这方法很纯粹,但如果网站庞大有很多对页面共享很少量元素时(<wbr></wbr>注:<wbr></wbr>比如30<wbr></wbr>对页面分别共享10<wbr></wbr>行代码)<wbr></wbr>,就显得很笨重了。<wbr></wbr>
创建一个单独的css<wbr></wbr>文件,包含所有共享元素的样式。这方法可能比较简单,却要取决于网站的大小和共享元素的多少。有种情况会很烦:<wbr></wbr>导入了一个很大的css<wbr></wbr>文件,但页面只用到一小部分样式——还是那句话,这违背了分离文件的初衷。<wbr></wbr>
这就是我所说的重叠的两难(overlap dilemma)<wbr></wbr>。零碎css<wbr></wbr>规则的重叠不一而足,并没有一个完全清晰无误的方案来组织它们。<wbr></wbr>
<wbr></wbr>
方法二:<wbr></wbr>基于页面元素/<wbr></wbr>块<wbr></wbr>
如果网站使用服务器端include<wbr></wbr>,这个方法会很不错。举例说明,如果使用页眉include<wbr></wbr>,它会有自己相应的css<wbr></wbr>文件。页脚或者其他部分的include<wbr></wbr>可以如法炮制,只须导入自己的css<wbr></wbr>文件。这个方法简单干净,不过可能会产生很多小css<wbr></wbr>文件。<wbr></wbr>
举例来说,假如页脚的样式只需要20<wbr></wbr>行css<wbr></wbr>代码,单独创建一个文件就划不来了。而且这个方法会导致每个页面都包含一堆css<wbr></wbr>文件——因为有多少include<wbr></wbr>,就得有多少css<wbr></wbr>文件。<wbr></wbr>
<wbr></wbr>
方法三:<wbr></wbr>基于标记<wbr></wbr>
这个方案直观实际,与前一个类似。如果网站共有30<wbr></wbr>个页面,其中10<wbr></wbr>个含有form<wbr></wbr>,那么可以创建一个css<wbr></wbr>文件专门处理form<wbr></wbr>的样式,只在这10<wbr></wbr>个页面导入它。如果另外10<wbr></wbr>个页面含有table<wbr></wbr>,就创建一个文件专门处理table<wbr></wbr>样式……诸如此类。