架构CSS　　在当前浏览器普遍支持的前提下，css被我们赋予了前所未有的使命。

然而依赖css越多，样式表文件就会变得越大越复杂。

与此同时，文件维护和组织的考验也随之而来。

　　(曾几何时)只要一个css文件就够了所有规则(rule)汇聚一堂，增删改都很方便可这种日子早已远去。

(现在)建立新网站时，必须花点时间好好筹划怎么组织和架构css。

　　文件的组织　　构建css系统的第一步是大纲的拟定。

(我认为)css组织规划的重要性堪比网站目录结构。

(注:用词夸张一点，让你加深记忆) 没有哪种方案放之四海而皆准，因此我们会讨论一些基本的组织方案，以及它们各自的利弊。

　　主CSS文件　　通常可以使用一个主css文件，来放置所有页面共享的规则。

这个文件会包含默认的字体、链接、页眉和其他等样式。

有了主css文件之后，我们开始探讨高级组织策略。

　　方法一:基于原型　　最基本的策略是基于原型页面(archetype page)分离css文件。

假如一个网站的首页、子页面和组合页设计不同，就可以采用基于原型的策略。

(这种策略下)每个页面都会有专属的css文件。

　　在原型数量不多的情况下，这个方法简单明了、行之有效。

然而，当页面元素并不按部就班的位于各个原型页时，问题就出现了。

如果子页面和组合页共享某些元素，而首页却没有，我们应该怎么做呢?　　把共享元素放入主css文件。

这虽不是最纯正的解决办法，却适用于某些具体情况。

可是如果网站庞大，(这样做的话)主css文件会迅速膨胀这就违背了分离文件的初衷:避免导入不必要的大文件。

　　在组合页和子页面的css文件里各放一份样式代码。

(这么做)就意味着要维护冗余代码，很显然我们不想这样。

　　创建一个新的文件，由这两种页面共享。

这听起来不错。

不过假如只有10行代码，我们创建这个文件仅仅是为了共享这10行代码?(注:杀鸡用牛刀?) 这方法很纯粹，但如果网站庞大有很多对页面共享很少量元素时(注:比如30对页面分别共享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就随便抛出编程的最佳实践。

像OOP、DRY、打开/闭合、与内容分离等这些规则应该应用到CSS里面。

无论你如何组织代码，都要确保方法真正帮助到你，并且使你的开发更加容易和可维护的。