问答：怎样规划CSS 中 的命名方式 怎样看待 CSS 中 BEM 的命名方式？

好多盆友 非常纠结 css命名规则 怎么弄，还没起步就被绊住了。那么今天蝈蝈就针对这个问题来讨论一下 没什么技术

含量。但却对效率开发至关重要的 “问题”。

下文是一些知乎大神的个人经验总结，假设认为实用请点赞 留言！  

 JS前端实用开发QQ群 ：147250970  欢迎添加~！

怎样看待 CSS 中 BEM 的命名方式？

BEM的意思就是块（block）、元素（element）、修饰符（modifier），是由Yandex团队提出的一种CSS Class 命名方法。

相似于：

.block{}
.block__element{}
.block--modifier{}

再烂的东西,假设真的毫无价值,是会立即被历史所淹没的

每一个领域都有沉淀下来对特定开发人员在特定场景实用的东西
非常赞同克军那句取其精华去其糟粕,何为精华,自己依据使用场景取舍

可能大多数同学看到那么多下划线中划线以及那么长我靠还有驼峰的名字,就会认为混乱和不爽
不爽是一个非常主观的词儿,他除了解决心理问题,没法解决生理问题

CSS这么多年并没有一个相对照较严谨的套路出来,宽松的写法导致团队成员写法各异,丢在页面都能跑起来,但混着做项目就不敢动或理不清别人写的代码
"这个CSS重写一遍比修改老文件快",这种念头差点儿全部人都曾有过.

我们团队用BEM快1年,以下我来谈谈一些心得

了解什么是 B.E.M

Block
!误区:这个block并不是inline-block里的block,
而是将全部东西都划分为一个独立的模块,一个header是block,header里嵌套的搜索框是block,甚至一个icon一个logo也是block
block能够相互嵌套

Element
!误区:假设一个Element-son是还有一个Element-father的子元素,
那么写法是 Block__Element-father__Element-son_Modifer,嵌套多了会非常长么?
不是的!!!
一个Block下的全部Element不管相互层级怎样,都要摊开扁平的属于Block
所以 BEM 最多仅仅有 B+E+M 三级,不可能出现 B+E+E+..+E+M 超长class名,也要求E不能同名

Modifier
之前我们常常写的 .current .active 等表达状态


从Class中解读B.E.M

我们常说CSS的凝视要写WHY,而不是写WHAT,看Class命名最好就知道是WHAT
BEM提出的一个概念是用连接符号来表达,它并不规定必须用什么连接符,但规定用不同连接符做团队内约定区分BEM 3类元素

比如我们组内约定
__双下划线代表B和E连接比如 menu__item
_单下划线代表B和M或E和M的连接 比如 menu_active 或 menu__item_active
-中划线同英语里做连字符比如 mod-menu 或 mod-menu__item 这里 B或E或M须要多个单词来描写叙述,就使用中划线

打字会抽搐吧...
你听说过Emmet么?再不济Zen Coding有听说过吧?实在不行听说过安利也行啊
FYI http://docs.emmet.io/filters/bem/

拆分Block到文件


我们并没实用BEM推荐的拆分CSS到很多其他文件夹里,图片是拆文件夹的.由于用的是 Grunt+LESS
团队项目特色为N个相互独立的移动端项目,Block并不会非常多,所以文件扁平化非常直观,带来的效率也相对高,如图为当中某个项目的css部分
另外,写block的时候须要新建less文件,字母排序,是否重名都非常清晰

按ctrl+f查找class定位和按快捷键打开文件名称没啥大差别,更何况新版LESS还有source map

最后我们团队正在开发相应模块管理的工具,目标是向NPM一样玩,同Alice一样规划解决方式

代码复用

代码风格可能文档里说的也不是非常详细,不如直接对着他们的页面按F12吧 http://beta.yandex.com/
BEM/OOCSS 风格对维护重用的class有极大帮助,适当的拆分block后组合,威力无穷

那个千年老栗子——假设我想将一个f30的类。改成f35怎么办？是挂羊头卖狗肉的直接将.f30{font-size:30px}改成.f30{font-size:35}吗？还是要进行全局搜索。修改全部的html的class名？
或者 Alice 里面的
.text-size30{font-size:30px;}
.text-size20{font-size:20px;}
.text-size10{font-size:10px;}

而我们採用的是相似 bootstrap 的方案
用程度来划分,而非详细数值,所以根本就不会存在.text-size30这么个类,那个写style上去有毛线差别.

在var.less里定义详细的数值

在 ui.less 里调用

BEM的不论什么一个block都能够到处用,这对模块并不多的手机项目非常有利.

关于hax大神吐槽的不用ID和后代选择器

ID
ID对于我和!important对于我一样,并不否认价值,但想不起来上一次用是啥时候了.
讲到这里顺便提一下 z-index的问题,有多少同学写z-index的时候会写1000+?有做过整站z-index规划么? 相同的用 class 假设能规划好了,我是不倾向用id,也想不到有什么非用ID不可的情况,性能什么的,呵呵,測过,影响不大
特定场景样例:在腾讯,JS和CSS是分别2种团队的人在写,我们约定ID给JS,class给CSS和固定前缀的JS hook,不管是不是BEM,ID在我们这两种团队约定下也是不使用,而且也没带来啥问题

后代选择器
这个BEM写block的时候是不用,但block相互嵌套的时候是用的,
比如一个状态下须要变动多个表现,用后代选择器一次性处理
性能以及JS/CSS代码可维护性都有明显优势
节选自 http://yandex.st/search_islands_www/0.2.15/desktop.bundles/index/_index.css

Tag selector 是翻译成标签选择器么
BEM是不同意用标签选择器的,一開始难以接受...
.menu li 能搞定的事情须要每一个 li 都写.menu-item

坏处
是 k 数添加么?

gzip下真不是个问题,或者是写代码额外工作量?这难道不是动态生成的么?

再不济编辑器也能够随便列编辑或复制当前行或代码提示啊

优点
就是避免 li 里的 li 受影响
举个样例,商品详情页是同意商家自己定义标签的,那么商家展示区域标签的祖先元素一旦用标签选择器定义了样式,子子孙孙都要背负.

所以十分赞同在无法百分百确定不会嵌套相同标签的情况下不用标签选择器


团队最重要的是统一
有一次讨论连字符用中划线还是下划线的时候,谁也说服不了谁,
最后一个掌勺的拍板,大家统一用一个,而非同一个团队多种风格.
这对上下游合作,内部合作都会极大的减少沟通成本

之所以用 BEM(部分),也是由于没找到更好的相似规范,尽管有缺陷,但至少能够统一
讨论一个东西,我们非常easy找出他的槽点,可是提出更好解决方式的同学少之又少,
从BEM中我们能够学习他优秀的方面纳为己用,
团队合作永远是统一高于一切

张克军 。豆瓣前端project师

SCSS让CSS变的更像编程语言。于是，非常自然的改变了CSS的传统组织方式。

 

关于BEM争议最大的就是它的命名风格。这样： 

 

• …
 

• …
 

 

block + element + modifier，鼓舞一级一级的写的非常详细，非常长。 

问题： 
1. 这么长，影响书写效率吧。肯定会影响但这是个非常大的问题吗（自己主动提示会缓解一些） 
2. html和css的size肯定会大一些。size大的顾虑是影响传输，在gzip面前能够忽略 
3. 不爽。的确非常违背习惯，但不论什么个人喜好和习惯作借囗都不职业 

风格不重要。我更关心它的优点： 
1. SCSS嵌套过多。超过3层就非常难阅读了。 
2. 嵌套多。选择器的层级就会多。性能不知不觉变差 
3. 复用。这么长的名，想冲突都难 

还有一个代码设计上的原则。不暴露抽象类。举例： 

曾经： 

 

• xxx
 

 

.list是抽象的列表类。

层叠的.list-member类。定义少量样类就能够实现一个成员列表的样式。 

可是在其他编程语言里抽象类是不会被暴露出来的。

借鉴BEM会是这样： 

 

• xxx
 

 

不在html里层叠抽象类，而是在SCSS里继承： 
%list { ... } 

.member-list { 
@extend %list; 
} 
.member-list__item { 
// 不同的样式规则 
} 

这样更符合编程的特点。重要的是在维护上。假如变样了须要继承还有一个抽象类。不须要改html，仅仅要改css。这样SoC更彻底。 

风格无非是某种形式，能够约束人做到一致。背后的设计思想才值得应用。假设用BEM的风格，但没做到抽象类的封装，没做到选择器的扁平，那就是失败的应用。

 

最后，我非常认同这种设计思想。但我还是不会照搬它的命名规则。太TM囧了。

最后我吐槽一句：我的这篇博文 排版 真tmd恶心啊！