谈CSS的设计模式

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

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

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

　　团队和个人

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

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

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

　　CSS和预处理器

　　前面我有文章详细的谈过CSS预处理器，我曾经对它也是排斥的，因为学习成本，因为觉得应用起来没有必要。可是一旦你决定去学习使用它，就会觉得不是那样，预处理器在向你介绍它自己的时候，就有特意强调过，它的语法是和CSS完全兼容的，也就是说，你在LESS或者SASS文件中，直接写CSS代码是没有问题的。除此之外，它能给我们提供很多便利，比如定义统一的变量；使用嵌套而不用一直重复着写一些选择器；可以提取公共的代码块然后很方便的复用等等。

　　故而，当我们已经把CSS组织和书写得很好了之后，预处理器，就是再次为我们插上一双翅膀，能更灵活和高效的编码。

　　从现有模式出发

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

　　一、OOCSS——Object Oriented CSS

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

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

　　separating structure from skin and container from content.

　　直译过来就是，结构和皮肤分离，容器和内容分离。

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

　　二、SMACSS——Scalable and Modular Architecture for CSS

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

　　它的核心是：

　　1、Base（基础）

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

　　2、Layout（布局）

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

　　3、Module（模块）

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

　　4、State（状态）

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

　　5、Theme（主题）

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

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

　　三、Meta CSS

　　原子类，也可以称之为“无语义”类，像这样：

　　它的特点是什么？样式和结构、内容无关，预先定义好这么一组规则，在需要的地方加上即可，我相信每个人第一次看到这种写法的时候，都会想：还能这样写啊？！是的，总有一些人，一些新的思想和方法会涌现出来，它就是其中之一，当然，并不是在称赞其本身有多么好，而是说这种现象和过程是好的，它本身经常被人吐槽，比如：“这样写和直接内联有区别吗？”、“如果要调整样式，就要去改HTML，维护更加麻烦，也有违样式和结构分离的初衷”等等，其实我个人也是不赞成上面这种写法的，如果你要把这些抽离出来，那么还有什么抽不出来的呢？而且这些属性，在项目之间，页面之间，模块之间，并没有太大的通用性，把这些抽出来，只不过是稍微懒省劲儿些，但为了照顾到更多情况，你必须写入冗余代码，是得不偿失的。

　　虽然它有缺点，我个人赞成另外的一些东西分出来，比如：浮动（float）、文本布局（text-align）、Flexbox布局等，这些是没有那么多可能性的值，而且使用频繁，复用方便，改动较少，除此之外，你还可以提取另外一些公共的小颗粒类，比如按钮的种类，文字颜色的种类等，这些和CSS本身无关，和项目相关，这就是借鉴其思想，而不是直接拿来用。

　　四、BEM

　　严格说来，BEM不是一套有骨有肉的模式，也不仅仅局限你在CSS的层面去规划，它是一种怎样去组织、编写代码的思想，而且，看似简单的它，对前端界的影响却是巨大的。

　　它的核心如下：

　　Block（块）、Element（元素）、Modifier（修饰符）

　　它帮助我们定义页面中每一部分的级别属性，从某种意义上说，也是一种“拆”。命名规则如下：

　　它的出现，曾给不少人带来启发，但是也有另一部分人仍然抱着挑剔的态度，譬如：

　　1、风格不统一，显得代码不够整洁美观

　　2、可能会导致类名过长

　　还是前面说的，你可以不去直接用它，但要清楚它的优点：能够使得我们仅通过类名就知道哪些代码是属于一个模块内，以及在模块中所起的作用。然后借鉴之。

　　当然，BEM集聚了很多人的心血，也得到了很多的赞誉，其中就包括OOCSS的作者。所以，它肯定不是这么简单。它还会告诉你，怎样配合着js来写，你的文件怎样组织更好，项目该怎么构建等。详细可以到官网去查阅。

　　从实际出发，决定结果的人是你

　　到底怎样使用设计模式？

　　虽然已经有成熟的设计模式，但在实际当中，你可能觉得哪个跟自己的项目都不能完全吻合，或者你要去为了使用它们而调整，成本很高。其实，我们不需要去迎合模式，要让模式为我所用，你需要去了解它们背后的原理，要知道它们用什么方式解决了什么问题，然后借鉴之，用它的方式解决我们的问题，就好，这样就不需要作难要不要用，也不需要纠结选哪个，不是简单的说哪个好，哪个不好，总有我们能够用得上它的地方。海纳百川，集百家众长。

　　我个人一直以来所坚持的另一个观点就是，前端开发的三驾马车——html、css、js，不要，也不能孤立的去谈那样好或者这样好，我们极少会有只用一次的代码或者模块，也不会只写一种语言，三驾马车都是在一起协作的，都是会有复用、扩展和团队合作多方面的因素在里面。故而，不能抱着这样的想法：我现在就在做这个，它就是唯一的，就是固定的，没问题。其实很多问题都是潜在的，要带着发展眼光去看待。项目的文件之间，项目之间，团队成员之间，不论你的分工是哪块，都要考虑到前后的影响和可能给合作带来的不便。

　　怎样才是最佳实践？有“实践”，才有“最佳”，脱离实际情况谈最佳，就是空中楼阁。那么，最好的模式，不是哪个经典的模式，而是在项目进行中，不断的磨合调整而出的。故而，不需要再惧怕看起来不明觉厉的设计模式，也不需要因为自己还不懂设计模式而郁闷，它就是人们总结出来的实战方法，你也可以有自己的模式~

更多谈CSS的设计模式 相关文章请关注PHP中文网！