CSS是一门15分钟就能入门，但是却需要很长很长的时间才能掌握好的语言。它有着它自身的一些复杂性与局限性。其中非常重要的一点就是，本身不具备模块化的能力。
面临的问题
CSS中虽然有@import功能。然而，我们都知道，这里的@import仅仅是表示引入相应的CSS文件，但其模块化核心问题并未解决——CSS文件中的任何一个选择器都会作用在整个文档范围里。
因此，其实我们面临的最大问题就是——所有的选择器都是在一个全局作用域内的。一旦引入一个新的CSS文件，就有着与预期不符的样式表现的风险（因为一些不可预测的选择器）。
而如今的前端项目规模越来越大，已经不是过去随便几个css、js文件就可以搞定的时代。与此同时的，对于一个大型的应用，前端开发团队往往也不再是一两个人。随着项目与团队规模的扩大，甚至是项目过程中人员的变动，如何更好进行代码开发的管理已经成为了一个重要问题。
回想一下，有多少次：
- 我们讨论着如何对class进行有效的命名，以避免协作开发时的冲突；
- 我们面对一段别人写的css、html代码，想要去修改，然后疯狂查找、猜测每个类都是什么作用，哪些是可以去掉的，哪些是可以修改的——到最后我们选择重新添加一个新的class；
- 我们准备重构代码时，重构也就成了重写
- ……
写一段CSS往往并不是困难所在，难得确实团队的合作与后续的维护。
What we want is to be able to write code that is as transparent and self-documenting as possible.
本系列文章会简要介绍一些CSS模块化进程中出现的一些方案。包括本篇要讲的BEM方法。
想要了解更多CSS模块化方案还可以阅读【CSS模块化】(1) webpack之Local Scope
BEM命名方法论
BEM其实是一种命名的规范。或者说是一种class书写方式的方法论（methodology）。BEM的意思就是块（block）、元素（element）、修饰符（modifier）,是由Yandex团队提出的一种前端命名方法论。在具体CSS类选择器上的表现就像下面这样
.block {}
.block__element {}
.block--modifier {}
.block__element--modifier {}
其中，block表示的是独立的分块或组件；element表示每个block中更细粒度的元素；modifier则通常会用来表示该block或者element不同的类型和状态。
举个例子，例如我们有一个列表
<ul class="list">
<li class="item">learn html</li>
<li class="item underline">learn css</li>
<li class="item">learn js</li>
</ul>
列表容器的class为.list，列表内每条记录的class为.item，其中，还为第二个条记录添加了一个下划线.underline。简单的css如下
.list {
margin: 15px;
padding: 0;
}
.list .item {
margin: 10px 0;
border-left: 3px solid #333;
font-size: 15px;
color: #333;
list-style: none;
}
.list .underline {
color: #111;
text-decoration: underline;
}
这样的命名方式，我们在阅读html时并不能迅速了解：.item是只能在.list中使用么，它是仅仅定义在这个组件内的一部分么？.underline是一个通用样式么，我想修改列表的中underline的记录为红色，这会影响到项目其他地方么？
这时候，我们就可以使用BEM方式来命名我们的class
.list {
margin: 15px;
padding: 0;
}
.list__item {
margin: 10px 0;
border-left: 3px solid #333;
font-size: 15px;
color: #333;
list-style: none;
}
.list__item--underline {
color: #111;
text-decoration: underline;
}
<ul class="list">
<li class="list__item">learn html</li>
<li class="list__item list__item--underline">learn css</li>
<li class="list__item">learn js</li>
</ul>
这段代码的一大优势就是增加了它的自解释性：一定程度上，它的class名本身就是一个简易的文档。
这里还需要避免一个误区，BEM命名规范里，我们的CSS并不会关心HTML中dom元素的层级结构。它的核心着眼点还是我们定义的块（block）、元素（element）、修饰符（modifier）这三部分。因为关注点不同，所以一个block内的所有element，在CSS中并不会考虑层级，因此也就没有.list__item__avatar这种写法
<ul class="list">
<li class="list__item">
learn html
</li>
<li class="list__item list__item--underline">learn css</li>
<li class="list__item">learn js</li>
</ul>
而是把这个img也看作block中的元素.list__avatar
<ul class="list">
<li class="list__item">
learn html
</li>
<li class="list__item list__item--underline">learn css</li>
<li class="list__item">learn js</li>
</ul>
从这个例子看一看出，CSS部分并不关心dom层级结构，而是在block下面有哪些element，这些element又有哪些modifier。
基于这个思想，我们可以知道，如果一个block里面含有其他block并不会违反BEM的原则。例如上面这个列表的例子，其中头像avatar原本只是一个简单的element，现在如果变成了一个很复杂的组件——包括图片、姓名和标签，那么可能会有这么一个block
<ul class="list">
<li class="list__item">
<div class="list__avatar">
<img class="list__head list__head--female" />
<span class="list__name"></span>
<span class="list__tag"></span>
</div>
learn html
</li>
<li class="list__item list__item--underline">learn css</li>
<li class="list__item">learn js</li>
</ul>
我们可以为avatar创建一个新的block
<ul class="list">
<li class="list__item">
<div class="avatar">
<img class="avatar__head avatar__head--female" />
<span class="avatar__name"></span>
<span class="avatar__tag"></span>
</div>
learn html
</li>
<li class="list__item list__item--underline">learn css</li>
<li class="list__item">learn js</li>
</ul>
那么你可能会有疑问，什么时候需要在将一个elment重新抽象为新的block呢？仅仅当我们的dom元素变得很多的时候么？
其实，BEM中的block一定程度上可以理解为一个“独立的块”。独立就意味着，把这一部分放到其他部分也可以正常展示与使用，它不会依赖其父元素或兄弟元素。而在另一个维度上面来说，也就是视觉设计的维度，当UI设计师给出UI稿后，其中的一些设计元素或组件会重复出现，这些部分也是可以考虑的。所以理解UI设计稿并不是指简单的还原，其中的设计原则与规范也值得揣摩。
从上面的简单介绍可以看出，BEM有着一些优点
- class的单一职责原则、开闭原则
- 模块化思想，一般来说遵循这个方法的组件可以迁移环境
- 一定程度上，避免命名的污染
- 自解释性。可以直观看出各个class之间的依赖关系以及它们的作用范围（
.list__item和.list__item--underline都是依赖于.list的，因此它们不能脱离于.list存在）
当然，BEM仅仅是一种命名规范或建议。在没有约束的情况下，你随时都可以违反。所以我们可以借助类似BEM-constructor的工具，既帮我们进行一定的约束，同时也省去一些繁琐的重复工作。在介绍BEM-constructor之前，我们还需要简单了解一下BEM-constructor中命名空间（namespaces）的基本概念。
约定项目的命名空间（namespaces）
命名空间（namespaces）也是一种关于CSS中class命名方式的规范。在BEM的基础上，建立命名空间主要是为了进一步帮助我们：
- 让代码能够自解释
- 在一个全局的context中安全地加入一个新的class
- 确保一个修改不会产生额外的副作用
- 在后期维护时能够迅速定位问题
命名空间分为以下几种。
Object: o-
当你使用面向对象的CSS（Object-Oriented CSS）时，o-这个namespace将会非常有用。
- 对象是一个抽象的概念。
- 尽量避免修改它们的样式。
- 如果要使用
o-时请慎重考虑。
Component: c-
c-应该是一个更为常见的namespace，表示Components（组件）。
.c-list {}
.c-avatar {}
从命名中我们就能知道：这是一个list组件；或者这是一个avatar组件。
- Components应该是一组具体的UI。
c-代表一个具体的组件。 - 修改它们非常安全，只会对组件产生影响。
Utility: u-
Utilities符合单一职责原则，实现一个具体的功能或效果。其概念有些类似JavaScript中的通用工具方法。例如一个清除浮动的Utility，或者一个文字居中的Utility。
.u-clearfix {}
.u-textCenter {}
由于Utilities作为一组工具集，在样式上具有更强的“话语权”，所以!important在Utilities中会更为常见。当我们看到下面这段HTML，我们会更加确信，这个大号的字体是.u-largeFont这个样式引起的。
<h1 class="title u-largeFont">namespace</h1>
- Utilities中的样式一般具有更高的权重.
- 不要滥用
u-前缀，只用在一些通用的工具方法上.
Theme: t-
当我们使用Stateful Themes这种定义主题的方式时（后续有机会会介绍一些“自定义主题”的方式），往往我们会在最外层容器元素中加入一个代表不同主题的class。这里就会用到t-。
- 主题
t-是一个高层级的命名空间。 - 一定程度上它和下面的Scope一样，也为其内部的规则提供了一个作用空间。
- 可以很明显地标识当前UI的总体状态（主题）。
Scope: s-
s-可能不是这么好理解，因为CSS中并没有Scope这个概念（或者说只有一个全局的Scope）。而s-正是希望通过命名的方式来建立一个新的Scope。
但是请勿滥用它，只有在你确实需要创建一个新的“作用域”的时候再使用它。例如一个简单场景：CMS。如果你接触过CMS你就会知道，它一定有一个生成或编辑内容的功能。而通常的，我们会将这部分编辑的内容输出到页面中，并在外部赋予一个新的Scope，用以隔离该部分与外部整个站点的样式。
<nav class="c-nav-primary">
...
</nav>
<section class="s-cms-content">
<h1>...</h1>
<p>...</p>
<ul>
...
</ul>
<p>...</p>
</section>
<ul class="c-share-links">
...
</ul>
.s-cms-content {
font: 16px/1.5 serif; /* [1] */
h1, h2, h3, h4, h5, h6 {
font: bold 100%/1.5 sans-serif; /* [2] */
}
a {
text-decoration: underline; /* [3] */
}
}
section部分就是展示CMS中的content（内容）。
- 首先，用到Scopes的场景确实非常的少，因此你准备使用时一定要仔细考虑
- 它的实现是要依赖于嵌套方式的（SASS/LESS中），也可以说是CSS后代选择器
慎用，需要万分小心。
在SASS中使用BEM-constructor
BEM-constructor是基于SASS的一个工具。使用BEM-constructor可以帮助规范并快速地创建符合BEM与namespace规范的class。BEM-constructor的语法非常简单。
npm install sass-bem-constructor --save-dev
首先在SASS引入@import 'bem-constructor';，然后使用@include block($name, $type) { ... }创建block，其中$name是block的名字，$type是namespace的类型（'object', 'component'和'utility'）。类似得，使用element($name...)和modifier($name...)可以快速生成block中的其他部分。
将最初的例子进行改写
@import 'sass-bem-constructor/dist/_sass-bem-constructor.scss';
@include block('list', 'component') {
margin: 15px;
padding: 0;
@include element('item') {
margin: 10px 0;
border-left: 3px solid #333;
font-size: 15px;
color: #333;
list-style: none;
@include modifier('underline') {
color: #111;
text-decoration: underline;
}
}
}
生成的内容如下
.c-list {
margin: 15px;
padding: 0; }
.c-list__item {
margin: 10px 0;
border-left: 3px solid #333;
font-size: 15px;
color: #333;
list-style: none; }
.c-list__item--underline {
color: #111;
text-decoration: underline; }
BEM-constructor支持我们之前提到的各种命名空间。例如theme($themes...)，scope($name)等等。语法格式基本类似。
此外，如果不想使用namespace，也可以手动关闭
$bem-use-namespaces: false; // defaults to true
同时也支持更改命名空间的前缀名
$bem-block-namespaces: (
'object': 'obj', // defaults to 'o'
'component': 'comp', // defaults to 'c'
'utility': 'helper', // defaults to 'u'
);
当然，如果你不喜欢BEM中的__，--的连接线，也可以自定义
$bem-element-separator: '-'; // Defaults to '__'
$bem-modifier-separator: '-_-_'; // Defaults to '--'
最后
BEM或者namespace是一种命名规范，或者说是一种使用建议。他的目的是帮助我们写出更易维护与协作的代码，更多的是在代码规范的层面上帮助我们解决CSS模块化中的问题。然而，也不得不承认，它距离我们梦想中的CSS模块化还有这很长的距离。但是无论如何，其中蕴含的一些组件化与CSS结构组织方式的想法也是值得我们去思考的。
想了解CSS模块化相关内容，可以看看
网友评论