前端的进击之路——CSS设计模式

什么是设计模式？

先来看一下比较官方的解释：”设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。”

今天让柳猫和大家一起来康康CSS的设计模式。

要对CSS进行设计，那么肯定是它本身存在一些问题或者缺陷，CSS的任何一个规则，都是全局性的声明，会对引入它的页面当中所有相关元素起作用，不管那是不是我们想要的。所以独立及可组合的模块是一个可维护系统的关键所在。

1. 从需求出发

1.1 分

刚开始，我们只是去定义规则，能用对了属性，语法正确，把页面实现出来了就大功告成了。慢慢地，就会发现，页面也是有结构的，我们按照页面的结构去组织代码，会不会更好？比如**，分成头部、导航、侧边栏、banner区、主内容区、底部等**。

然而这样貌似还是不够，因为还有一些东西，复用度是很高的，又不好把它归为任何一个固有模块，比如：面包屑、分页、弹窗等，它们不适合被放到某一个固有模块的代码中，就可以单独的分出一段专属的css和js，这就是组件化的由来~

1.2 拆

在分了之后，代码看起来已经比之前好很多了，组织清晰，维护性大幅提高，但是还是不够，我们会发现另外一些东西，很细小，但复用度也很高，它们同样不适合被放到模块中去，比如，边框、背景、图标、字体、边距、布局方式等等。如果我们在每个需要它们的地方，都定义一次，它们会被重复很多次，会造成代码冗余和维护困难。拆过之后想在哪里用就可以直接加，需要改的时候统一改。

1.3 排

经过了“分”、“拆”，代码结构已经十分清晰，各个内容模块，功能模块，UI模块都乖巧的等待召唤，那么还差什么？还差有序的组织，分类清晰之后，还需要排列有序，像这样：

@import “mod_reset.css”;
@import “ico_sprite.css”;
@import “mod_btns.css”;
@import “header.css”;
@import “mod_tab.css”;
@import “footer.css”;

将不同的部分按照一定的顺序去摆放，有利于进行继承或层叠覆盖。这一步要求比较高的统筹规划能力，可以减少冗余代码和快速定位问题位置等。

除此之外，也有其他的方法来帮助我们进行区分代码范围，比如：

1、在文件头部建立一个简要的目录

/**
*   RESET       重置默认样式
*   FONT-FACE   引入字体文件
*   ico         公用图标
*   btn         公用按钮
**/

2、使用区块注释

/*----------------------------------------
RESET
-----------------------------------------*/

在注释中，应该尽量详细的写清楚该段代码的目的，状态切换，调整原因，交互逻辑等等，这样不仅利于自己的维护，更加利于别人接手维护你的代码。

2. 从结论出发

除了需求当中一些通用部分，另外一些也是需要注意，但不会被正式定义的东西，它们来源于实践经验，比如：

2.1 层级嵌套不要太深

浏览器在解析CSS规则的时候，是从右向左，一层层的去遍历寻找，如果层级太多，必然增加了渲染时间，影响渲染速度。

一般建议是不超过4层，但超过4层会怎样吗？不会有多明显的影响，除非你写到很恐怖的数量，或者项目极其庞杂，可能能看出来影响，其实从日常需求来看，4层以内足可以解决绝大多数问题。

2.2 避免使用元素选择器

出于两点考虑：

第一点，和上一段提到的相关，在HTML中，有很多常用的高频元素，比如，div、p、span、a、ul等，如果，你在多层选择器的最内层使用了元素选择器，那么，在开始寻找时，浏览器就会遍历HTML中的所有该元素，显然，这是没有必要的。

第二点，我们的需求和代码结构都是存在着潜在变化的，已经写好的一个结构，随时可能被复用到别的结构中去，如果使用了元素选择器去定死某个东西，不论是新加进来的东西，还是被复用的东西加到别的结构里去，都极有可能产生样式的冲突，这个时候，我们又不得不写多余的样式进行覆盖修正，或者重新定义类。

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

2.3 避免使用群组选择器

群组选择器会有什么问题？

.header ul li
.content ul li
.footer ul li

border-left:3px solid blue;

这种情况不多见，此处只是举个例子，这里写了三组选择器，用来定义不同地方的同一种样式，其明显的缺陷是，如果有第四个地方需要使用到，你不得不再往里加一组选择器，如果有10个不同的地方，你就写10个？这对于维护来说，是很痛苦的，完全可以提取出来一个公用类，定义统一样式，然后，哪里需要放哪里，复用和维护都会更加方便。

2.4 文件引入的数量和顺序

对于刚接触网页的朋友来说，这两点也是容易忽视的，因为它们看起来没什么大影响，多几次请求，样式是否已经加载，都没那么容易把人逼疯，但是出于对用户体验的极致追求，我们还是希望文件请求次数尽量少，内容的显示有个优先顺序，文件加载有个先后顺序，这样，在实在难以缩减文件大小的时候，让用户先看到更重要的，正常展示的内容。

以上只是几点举例，更多实战结论，大家可以多读相关的博文或者书籍，都会有前辈们的经验之谈。

3. 从矛盾出发

3.1 通用和语义

命名规则有助于立即理解一个特定样式属于哪一类，它在页面的整体范围内的作用。在大型项目中，它更可能有在多个文件中被打破的样式。在这种情况下，命名约定也可以更容易地找到一个样式属于哪个文件的文件。

一个被定义为通用的东西是便于复用的，比如：模块标题、按钮、提示文字、图标等，最开始的时候，我们习惯去看视觉稿的内容，是“新闻”，我们就定义“new”，是“关于”，我们就定义“about”，是红色的按钮，我们就定义“red-btn”等，这样会导致一个问题，如果有另外一个跟新闻列表差不多的样式和结构，但不是新闻，怎么办？继续使用“new”显然不合适，这就告诉我们，不能把目光局限于内容，需要内容和结构分离。

不能用“new”了，那用什么呢？abc？123？这样总不会冲突了吧，万事大吉~其实，这是走了另一个极端，这样虽然在很大程度上避免了和别的模块冲突，但其本身的可读性就被大大降低了，别人，甚至你自己过一段时间都会忘记它是什么，对于团队合作是很不利的。至于需要用什么样的命名方式，需要你根据项目的整体来进行规划，适合根据什么特点来区分与之不同的结构，又能让人比较容易的在名称和结构之间建立联系，比如所属类别、功能、页面等。

3.2 团队和个人

一个团队当中，大家的经历不同，编码水平和习惯也不同，这样就会造成，一个人一个写法，你用中划线，我用下划线；我用英文全拼，你用简写，等等。这些虽然没有什么对错之分，但对于团队成员之间的协作造成了不小的障碍，别人必须花时间去适应和读懂你是怎样组织和定义的，这就无形之中提高了成本。

所以，就有了“团队规范”存在的必要，规范除了一些写法上的规定，让我们的代码更加统一，清晰，可读性更强，辨识度更高。还可以提取一些最佳实践和复用模块等，对于团队里每个人来说，都是有好处的。

当然，对于人来说，最难的，莫过于调整既有的习惯，这就会有进入一个团队之后“转型”的阵痛，其实这种痛也是成长的痛，你会学习到更好的编码方式，更好的实践方法，会从项目或者团队的整体去考量一件事的价值和意义。

4.从现有模式出发

再来简单看看一些广为流传的模式。（ps：先后顺序与排名、好坏无关）

4.1 OOCSS——Object Oriented CSS

接触过计算机的应该都知道，OOP——Object Oriented Programming，如果你是第一次接触OOCSS，你会很困惑，难道是“面向对象的CSS”吗？它不是一本真正的编程语言啊，如何面向对象？

OOCSS，最早被提及，是在2009年，它的两大原则是：

separating structure from skin and container from content.

即不要把结构和皮肤以及内容进行强耦合，而是相互独立，所要达到的目标是更易复用和组合，可以选择使用，选择引用等。

4.2 SMACSS——Scalable and Modular Architecture for CSS

从实践上说，OOCSS给出了一种值得借鉴的思想，但在代码的组织方面，它并未给出具体的实施方法，从这一点上来说，SMACSS更进一步。

它的核心是：

1、Base（基础）
基础的样式，就是一些需要最先定义好，针对于某一类元素的通用固定样式。

2、Layout（布局）
布局样式，是跟页面整体结构相关，譬如，列表，主内容，侧边栏的位置、宽高、布局方式等。

3、Module（模块）
模块样式，就是我们在对页面进行拆的过程中，所抽取分类的模块，这类的样式分别写到一起。

4、State（状态）
页面中的某些元素会需要响应不同的状态，比如，可用、不可用、已用、过期、警告等等。将这类样式可以组织到一起。

5、Theme（主题）
主题是指版面整个的颜色、风格之类，一般网站不会有频繁的较大的改动，给我们印象比较深的是QQ空间，其他应用的不是很多，所以，这个一般不会用到，但有这样一个意识是好的，需要用到的时候，就知道该怎样规划。

有了以上5点分类策略，代码组织起来，思路就会很清晰，会安排的很有序，另外的好处是，可以解决命名难和混乱，之所以有这个问题，主因便是我们不知道以怎样的标准去定义元素的所属和特点，有了分类之后，我们不会很随意和混乱的去命名，有了依据，就能更轻松，也不易冲突。

到底怎样使用设计模式？

虽然已经有成熟的设计模式，但在实际当中，可能觉得哪个跟自己的项目都不能完全吻合，或者要去为了使用它们而调整，成本很高。其实，我们不需要去迎合模式，要让模式为我们所用，需要去了解它们背后的原理，要知道它们用什么方式解决了什么问题，然后借鉴之，用它的方式解决我们的问题，这样就不需要纠结选哪个，不是简单的说哪个好，哪个不好，总有我们能够用得上它的地方。海纳百川，集百家众长。前端开发的三驾马车——html、css、js，柳猫希望大家都能够和他们一起愉快的玩耍~