CSS设计模式-白红宇

CSS设计模式

阅读量：5925 次

发布时间：2019-06-19

本文共 3543 字，大约阅读时间需要 11 分钟。

关于web设计的网站

什么是设计模式？

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

今天我们来聊聊CSS的设计模式。

设计模式，这个词汇我们常见，几乎所有的编程语言都会有几套，但深入研究的人不多，原因如下：

似乎没有太大必要性去强调它，有问题了改一下或者按团队规范来就行；

不去使用一些既有的模式也无伤大雅；

不少人所接触的业务量级还没有达到需要规划和组织的程度，光写布局，写特效，照顾兼容，就够喝一壶的了，没有意识去思考一些方法论的问题。

我们都会长大，都会慢慢的做更多、更大、更复杂的项目，这个时候，就需要自上而下，全流程的去思考一些问题，后台不说，只讲前端，比如：风格的制定、色调、模块、布局方式、交互方式、逻辑等等，如果再加上团队合作，若再没有一个规划的话，要不了多久，那些看起来没问题的代码，就会暴露出各种问题，模块命名、类的命名、文件的组织、共用模块的提取、代码的复用、可读性、扩展性、维护性。它们看起来只是一些简单的小动作，却需要你看得更远，避免将来出问题需要付出更大的代价，甚至被迫整个项目重构，可谓，功在当代，利在千秋~

既然要对CSS进行设计，那么肯定是它本身存在一些问题或者缺陷，其中，一个最明显的就是，它的任何一个规则，都是全局性的声明，会对引入它的页面当中所有相关元素起作用，不管那是不是你想要的。而独立及可组合的模块是一个可维护系统的关键所在。下面，我们就从多个层面来探讨一下，到底该怎样写CSS，才是更科学的。

从需求出发

分

我们刚开始学习写字的时候，是不会去考虑，写出来的某句话好不好，文章结构合适不合适，因为我们是意识不到的。写代码也一样，刚开始，我们只是去定义规则，能用对了属性，语法正确，把页面实现出来了，就好。慢慢地，就会发现，页面也是有结构的，我们按照页面的结构去组织代码，会不会更好？比如，分成头部、导航、侧边栏、banner区、主内容区、底部等。

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

拆

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

排

经过了“分”、“拆”，我们的代码结构已经十分清晰，各个内容模块，功能模块，UI模块都乖巧的等待召唤，那么还差什么？是的，还差有序的组织，分类清晰之后，还需要排列有序，从不同纬度去考量，我们总能精益求精。举个栗子，我们可能会看到像这样：

@import “mod_reset.css”;

@import “ico_sprite.css”;

@import “mod_btns.css”;

@import “header.css”;

@import “mod_tab.css”;

@import “footer.css”;

我们将不同的部分按照一定的顺序去摆放，能让我们的代码看起来更加有序，易于维护，同时，有利于进行继承或层叠覆盖。不要小看这一步，看似可有可无，实际要求比较高的统筹规划能力，可以减少冗余代码和快速定位问题位置等。

从结论出发

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

层级嵌套不要太深

稍微了解一些浏览器渲染原理的都知道，它在解析CSS规则的时候，是从右向左，一层层的去遍历寻找，如果层级太多，必然增加了渲染时间，影响渲染速度。另外，如果选择器层级过多，也就间接反应了，你的HTML结构可能写得不够简洁。

那么具体多少层合适？一般建议是不超过4层，但话又说回来，超过4层会怎样吗？不会有多明显的影响，除非你写到很恐怖的数量，或者项目极其庞杂，可能能看出来影响，其实从我们日常需求来看，4层以内足可以解决绝大多数问题，故而，是合理的。

避免使用元素选择器

出于两点考虑：

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

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

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

避免使用群组选择器

从现有模式出发

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更进一步。