CSS 命名规范

我们总是希望编写可读性强且易于维护的 CSS 代码，我们应该寻找一种方法来解决它。

BEM

BEM解决这一问题的思路在于，由于项目开发中，每个组件都是唯一无二的，其名字也是独一无二的，组件内部元素的名字都加上组件名，并用元素的名字作为选择器，自然组件内的样式就不会与组件外的样式冲突了

Summary: 通过组件名的唯一性来保证选择器的唯一性，从而保证样式不会污染到组件外

BEM的命名规矩很容易记：blockname_elementname-modifiername，也就是模块名 + 元素名 + 修饰器名, 只需保留BEM的思想，其命名规范可以任意变通

BEM的命名中只包含三个部分，元素名只占其中一部分，所以不能出现多个元素名的情况，BEM是不考虑结构的, 不会因为名字变动，牵涉到JS文件的修改，或样式文件的修改。

子代选择器不好的地方在于，如果层次关系过长，逻辑不清晰，非常不利于维护。为了懒得命名或者追求所谓的“精简代码”。 

.page-btn ul li a {}

用层次关系结构关系来定位元素，可能会因为需求改变而大面积的重写样式文件

我为了改一个元素的代码，需要不断翻阅HTML文件和CSS文件，可维护性非常之差。 更有甚者，来维护这块代码的同事，直接在样式文件最后添加覆盖样式，这会造成一个非常严重的问题了：同一个元素样式零散的分布在文件的不同地方，而且定位该元素的选择器也可能各不相同。

子代选择器还会造成权重过大的问题，当我们要做响应式的时候，某个带样式的元素需要适配不同的屏幕，此时，我们还要不断的确认该元素之前的选择器写法！为了覆盖前面权重过大的样式，甚至通过添加额外的类名或标签名来增加权重。可想而知，此后这个样式文件的维护难度就像雪球一样，越滚越大。

BEM禁止使用子代选择器。 

Atomic 

“pull-right”、"ellipsis"、“clearfix”等等类，这些类非常实用，和BEM是可以互补的。

原子类更适合应用在实际页面中，这是因为页面变动大而且不可复用，假设在header中，我们用到了两个组件logo和user-panel（用户操作面板），两个组件分别置于header的左侧和右侧，我们可以这么写：

<div class="header clearfix">
    <div class="logo pull-left"><!-- ... --></div>
    <div class="user-panel pull-left"><!-- ... --></div>
</div>

BEM主要被诟病的一点在于其命名过长，结合Angular这种带有标签指令的框架时，整个HTML看起来会更混乱。

结构化命名

结构化的标记意味着表达方式/位置信息同内容的完全分离——这其中包括出现在标记（markup）中的类和id名称。

有标记的相关信息都是用来描述文档的结构而不是外观。这样的特点使得我们可以通过简单的改变CSS的方式来对不同外观格式下的内容（content） 以及标记（markup）进行重用。当你理解这种方式时，很容易就可以发现采用页面位置来为类以及id命名的方式在处理如音频（audio） 等外观格式上显得非常不合适。因此，应当根据在文档中的使用目的而非出现位置来对类以及id进行结构化命名。

可以按照如下所示的结构 化方式来对类以及id名称命名：

branding
main-nav
subnav
main-content
sidebar

这些名字同直观命名方式一样非常易懂，但他们描述了页面元素的作用而非位置。这使得代码更加符合使用纯粹的结构化标记（structural markup）的初衷，即开发人员可以在不改变标记的情况下对各种各样媒体下的显示格式进行处理。

即使你不打算在其他的媒体上对 Web页面进行格式修改，使用结构化命名方式还可以帮助你在日后的站点升级或重新设计中更为轻松。结构化命名避免了当一个div同 id right-column移动到页面左边后所带来的混乱。对div sidebar的采用这样的命名方式就显得更加适当，因为无论 它出现在页面的哪一边，这个名字仍然对开发人员来说直观易懂。

这里给出了最常用类/id名称的示例列表：

header
content
nav
sidebar
footer

#divBlue,在改版时我们希望把这个DIV做成绿色，那这个ID根本就是个错误了！（改版 需要改变 id对应的css样式）

“.textRed{color:#f00;}” 作为原子类来使用，因为我们需要在一些特定的地方使用这样的CLASS来定义文本为红色。（改变 html出现类的位置）