谈CSS的设计模式

拆
　　在分了之后，我们的代码看起来已经比之前好很多了，组织清晰，维护性大幅提高，但是，好像还是不够，我们会发现另外一些东西，很细小，但复用度也很高，它们同样不适合被放到模块中去，比如，边框、背景、图标、字体、边距、布局方式等等。如果我们在每个需要它们的地方，都定义一次，它们会被重复很多次，显然，这背离好的实践，会造成代码冗余和维护困难。所以，我们需要"拆".拆过之后会怎样？我们想在哪里用可以直接加，需要改的时候统一改。
　　排
　　经过了"分"、"拆",我们的代码结构已经十分清晰，各个内容模块，功能模块，UI模块都乖巧的等待召唤，那么还差什么？是的，还差有序的组织，分类清晰之后，还需要排列有序，从不同纬度去考量，我们总能精益求精。举个栗子，我们可能会看到像这样：

@import "mod_reset.css";
@import "ico_sprite.css";
@import "mod_btns.css";
@import "header.css";
@import "mod_tab.css";
@import "footer.css";

　　我们将不同的部分按照一定的顺序去摆放，能让我们的代码看起来更加有序，易于维护，同时，有利于进行继承或层叠覆盖。不要小看这一步，看似可有可无，实际要求比较高的统筹规划能力，可以减少冗余代码和快速定位问题位置等。
　　除此之外，我们依然可以有其他的方法来帮助我们进行区分代码范围，比如：
　　1、在文件头部建立一个简要的目录
　　2、使用区块注释
　　在注释中，应该尽量详细的写清楚该段代码的目的，状态切换，调整原因，交互逻辑等等，这样不仅利于自己的维护，更加利于别人接手维护你的代码。
　　从结论出发
　　除了需求当中一些通用部分，另外一些也是需要注意，但不会被正式定义的东西，它们来源于我们的实践经验，比如：
　　层级嵌套不要太深
　　稍微了解一些浏览器渲染原理的都知道，它在解析CSS规则的时候，是从右向左，一层层的去遍历寻找，如果层级太多，必然增加了渲染时间，影响渲染速度。另外，如果选择器层级过多，也就间接反应了，你的HTML结构可能写得不够简洁。
　　那么具体多少层合适？一般建议是不超过4层，但话又说回来，超过4层会怎样吗？不会有多明显的影响，除非你写到很恐怖的数量，或者项目极其庞杂，可能能看出来影响，其实从我们日常需求来看，4层以内足可以解决绝大多数问题，故而，是合理的。
　　避免使用元素选择器
　　出于两点考虑：
　　第一点，和上一段提到的相关，在HTML中，有很多常用的高频元素，比如，div、p、span、a、ul等。如果，你在多层选择器的最内层使用了元素选择器，那么，在开始寻找时，浏览器就会遍历HTML中的所有该元素，显然，这是没有必要的。
　　第二点，我们的需求和代码结构都是存在着潜在变化的，今天写好了一个页面，明天可能就要再加进去一个按钮，再加进去一句话，再加进去一个图标。我们写好的一个结构，也随时可能被复用到别的结构中去。所以，如果，你使用了元素选择器去定死某个东西，不论是新加进来的东西，还是被复用的东西加到别的结构里去，都极有可能产生样式的冲突，这个时候，你又不得不写多余的样式进行覆盖修正，或者重新定义类。

　　所以，出于以上考虑，在具体的代码模块中，尽量不要使用元素选择器，使用元素选择器的前提是，你完全的确定，不会导致出现问题。注意，我用的限定范围是"具体的代码模块",那么用于定义通用规则的样式，是可以的，也是推荐使用的，比如，reset.也可以是别的地方，这就需要我们自行考量。