架构css
在当前浏览器普遍支持的条件下，css被我们赋予了前所未有的使命。然而依靠css越多，样式表文件就会变得越大越复杂。与此同时，文件维护和组织的考验也随之而来。
(曾几何时)只要一个css文件就够了——所有规则(rule)汇聚一堂，增删改都很利便——可这种日子早已远去。(现在)建立新网站时，必需花点时间好好操持怎么组织和架构css。
文件的组织
构建css系统的第一步是大纲的拟定。(我以为)css组织规划的重要性堪比网站目录结构。(htmlor注:用词夸张一点，让你加深记忆) 没有哪种方案放之四海而皆准，因此我们会讨论一些基本的组织方案，以及它们各自的利弊。
主css文件
通常可以使用一个主css文件，来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉和其他等样式。有了主css文件之后，我们开始探讨高级组织策略。
方法一:基于原型
最基本的策略是基于原型页面(archetype page)分离css文件。如果一个网站的首页、子页面和组合页设计不同，就可以采用基于原型的策略。(这种策略下)每个页面都会有专属的css文件。
在原型数目未几的情况下，这个方法简朴明了、行之有效。然而，当页面元素并不按部就班的位于各个原型页时，题目就泛起了。假如子页面和组合页共享某些元素，而首页却没有，我们应该怎么做呢?
把共享元素放入主css文件。这虽不是最纯正的解决办法，却合用于某些详细情况。可是假如网站庞大，(这样做的话)主css文件会迅速膨胀——这就违反了分离文件的初衷:避免导入不必要的大文件。
在组合页和子页面的css文件里各放一份样式代码。(这么做)就意味着要维护冗余代码，很显然我们不想这样。
创建一个新的文件，由这两种页面共享。这听起来不错。不外如果只有10行代码，我们创建这个文件仅仅是为了共享这10行代码?(htmlor注:杀鸡用牛刀?) 这方法很纯粹，但假如网站庞大有良多对页面共享很少量元素时(htmlor注:好比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文件里的某些规则可能就得重新考虑。
另外，品牌联合也可能是一个重要因素。(htmlor注:如google和nike联手推出的joga) 假如涉及品牌联合，你就得考虑哪些元素应该调整以适应另一品牌。好比分别使用不同的css文件等。
还有一个常被忽略的技巧:使用嵌套的@import语句。只包含一连串@import语句，或者再加几句css规则，就能创建一个css文件。用这个方法完全可以创建网站的主css文件(用@import导入各部门的样式文件)。如果网站的每个页面都导入了4到5个不同的css文件，无疑你应该考虑使用这个技巧。
规则和选择器的组织
谈完了文件组织，接着讨论一下怎么组织文件里的东西吧。很天然，我们但愿在文件里畅通无阻的浏览，迅速找到要编纂的选择器(selector)或规则。
冗余 vs. 附属
正如Dave Shea在其文章《冗余 vs. 附属》(Redundancy vs. Dependency)里所说的，你必需不断了解级联(cascade)。你要决定是对选择器编组(意味着附属)，仍是把它们分离(意味着冗余)。编组可以保持代码简洁简要，可是会建立附属关系，导致维护开销增加。假如不编组，就会增加文件大小，让相似的选择器保持一致变得难题。只有做好这种权衡、取舍，才能每次都作出准确的决定。
