BEM是Block, Element, Modifier。
一种class的命名习惯。在这种CSS方法学中，一个block就是一个component的顶级抽象，例如一个button: .btn { }。这里的block应该被当作是一个parent，child items 或者elements, 可以被放在block里面，然后 用在block 名字的后面加两个下划线的方式来表明，例如： .btn__price { }
最后，modifier可以用来操作block, 这样我们就可以style 特定的component， 而且不会给完全不相关的module 造成影响。modifier用两个加在block 名字后面的 hyphens(连字符)来表示，例如： btn--orange 。
如果另一个developer写了这个markup, 并且我们对CSS也不太熟悉，我们仍然有很好的办法去区分哪些classes 是负责什么的和它们之间是怎么互相依赖的。接下来developer就可以build它们自己的components或者修改已经存在的block，去构建它们想要的内容。不用写太多的CSS，用这些在markup里面的class, developer就可以简单的创建许多不同的组合。
为什么我们应该考虑BEM？
设计师和developer可以一致的去命名components，因为团队成员的沟通交流变得更简单了。换句话说，就是BEM给了每个项目成员一个语法说明，每个人都能更容易的看懂它，并且相互分享。
所以，如果一个developer可以在一个project更加自信的工作，那么它们就会更加确定去做一些更聪明的决定，关于这些视觉component如何被使用的。对于这些小的ailments(疾病)来说，这个方法学或许不是一个完美的解决方案，但是他必定给了developer一个标准，在将来怎样去写更好，可操作性更强的code。
关于BEM，另一个聪明的部分就是 everything is a class and nothing is nested. 这样使得CSS的特性变的非常扁平和单一，这是一个好想法。这意味着你最终不会因为这种差异性和自己斗争。
让我们来看看一些和BEM相关的问题。
Problems with BEM CSS
当然，如果你打破了BEM的规则也 没有人会扭曲你的胳膊。你可以仍然想这样去写一个CSS selector:
这段代码看起来好像只有一部分BEM在进行，但是它不是BEM。他有嵌套的selectors，并且modifier 甚至没有准确的描述到底发生了什么事。如果我们这样做的话，我们会破坏在BEM中非常有用的扁平特性。
一个block(例如: .nav) 应该绝不会重写其他block或者modifier的styles (例如： .btn?orange)。否则 这将会使它几乎可以去读整个HTML，并且会让我们分不清这个component到底干了什么。在这个过程中，我们势必会使其他developer对代码库的信心造成巨大的动摇。
如果你看到下面的markup，你会怎样认为呢？
这里的问题是，在一个完全的block里面的一个element，有developer需要的code, 但是child elements 没有像它的parent一样，require一个.nav class，这就造成了格外confusing和不一致的代码库。这是应该不惜任何代价避免的。我们可以总结成以下两个问题：
More examples of BEM in action
Accordion demo
在这个例子中，这里有一个block,两个elements和一个modifier。 这里我们已经可以创建一个 .accordion__copy?open modifier可以让我们知道我们不能够在其他的block或者element里面使用它。
Navigation demo
这个navigation demo有一个block，6个elements和0个modifiers, 并且它完全可以去创建blocks在没有modifiers的情况下。在未来的某个时刻，developer可以总是连接在新的modifiers很久，因为block会保持不变。
Dislikes of BEM
或许你不喜欢dobule-underscores 或者 double-dashes。没问题，用其他任何你会坚持使用的特殊字符都可以。
Sass and BEM
你可以写继续enjoy嵌套的Sass写法, 但可以用 @at-root得到不嵌套的CSS。
Summary
为了wrap things up，我认为很公平的说，虽然BEM没有解决所有我们的问题，但是它对创建可扩展的构造仍然非常的有用，在团队每个人应该有一个清晰的idea关于怎样提高code质量的地方保持了界面。这是因为一个巨大的前端开发不仅仅是在短期内关于解决一个小问题nice tricks ，我们需要协议，pormises和有约束力的社会契约在developers之间，以便我们的代码库可以适应时间的变化。
原文： https://css-tricks.com/bem-101/
https://css-tricks.com/strategies-keeping-css-specificity-low/
example:
版权声明：本文为博主原创文章，未经博主允许不得转载。
