提到 CSS 不得不说到 禅意花园，相同的 DOM 的结构，因为加载不同的 CSS 文件，即可呈现不同的视觉效果，甚至简单的交互。
但是，正因为这种几乎没有限制的使用，给开发中带来了不小的问题。也因此，出现了很多的方案。
略过 Dreamweaver 等工具生成页面的混乱时代，自开始手工代码开始，Pure 的 CSS Style 就算是一个必须的要求。
对页面进行简单的分区，给不同的分区加上 ID 选择器（或者唯一的 Class，甚至 Attr 选择器），然后再细化，通过不同的子选择器来 Style 子元素。
DOM:
header#header
h1 我是标题
nav.header-nav
ul
div#main
footer#footer
p copyrights
CSS:
#header{}
#header h1{}
.header-nav{}
.header-nav ul{}
#main{}
#footer{}
#footer p{}
简单，干净，如果是个人维护的页面，修改起来也会相当方便，但同时也会带上各种个人的习惯。上节中的禅意花园的各样式，也因此，几乎是唯一可用了。所以，对于不同类页面，几乎是每次都得重复工作。
人总是喜欢偷懒的，所以提出了 Object Oriented CSS 的方案，对于大部分包含 Web Components 的 CSS 框架都会有这么一种应用，比如常见的 Bootstrap、Foundation、Pure 等。
另外，更普及的 Grid System 更是这种方式的应用。用 BootStrap 的 Grid 举个例子：http://getbootstrap.com/css/#grid
它把整个页面的主要内容列，分割成了 12 个子列，然后通过对 .row 下的子容器进行组装,
DOM(with emmet)
div.row>div.col-md-1*12
div.row>div.col-md-8+div.col-md-4
如此，这部分对整体布局的样式就不用再做额外的工作，丢给 DOM 组装即可，以实现任意的比例的列布局。同样的，比如 button form 等，较为通用的样式，用这种方式会非常方便的复用。当然，OO-CSS 和 Pure Flow 是可以结合使用的，整体 Pure Flow 布局，结合 Grid System 对内容分栏，然后局部调用一些被复用的小组件。
但是，OO-CSS 一个很大的问题，因为很多的复用，当基础样式做了修改后，需要对整套页面进行检查与更新，以确保所有视觉效果正常。用了 Bootstrap 2 再更新到 Bootstrap 3 就能体会到了。所以，对于多 Page 应用这并不算是个好方案，当然对于 Single Page App，OO-CSS 使用起来会相对顺手。
Developer A 设计了 .btn 作为公共样式，.btn-primary 等作为扩展样式。以 button.btn.btn-primary 的方式来使用。再约定的规则下，Developer B 在做扩展的时候，定义一个 .btn-info
即可完成这一新的样式 button.btn.btn-info，这也是 OO-CSS 带来的一种好处。
LESS 和 SASS 这类预编译的方案的出现，大概也是为了解决页面不断修改的需求吧。当然，它们也提供了一些简单语法方案，用作批量生成，计算等。
把一些常见的变量提取出来，甚至把整个对象抽离出来，作为原型。
变量 => Components 原型 => Components 实例
LESS Demo:
@fontSizePrimary:14px;
@colorPrimary:#666;
.headingStyle(@fontSize;@fontColor){
font-size:@fontSize;
color:@fontColor;
};
#header h1{
.headingStyle(@fontSizePrimary,@colorPrimary);
}
当然，LESS/SASS 这类毕竟不是浏览器原生支持的文件（要在浏览器中使用，LESS 要引入 less.js；SASS 则仅 Chrome 有）。所以，这种预先编译往往会包含到一个完整的工作流中。
src => dist
代码的管理仅仅在 src 目录中，而不要对于 dist 不要做任何修改（将它们当做被编译的不可直接修改的结果）。
也因此，LESS 等对于小型项目就显得有点多余了。
Pure Flow 搭建整体布局，OO-CSS 给予组件复用的便利，预编译方案将一些变量抽出管理以应对变化，看上去已经能解决大部分问题了。
不过，为了进一步整合上面的内容，近年来又火了一个 BEM。
BEM 最大的好处是解决了多级嵌套的问题。Pure Flow 中常见的 .xxx ul li ul li{} 这种方式会不复存在。取而代之的是精确的选择器定位。
同样，理应避免原型的暴露，
ul.list.list-member
li
以前的写法会被
ul.member-list
li.member-list__item
所代替。
利用 LESS/SASS 可以将这种被暴露的继承，交给预编译当中。
LESS:
.list(){}
.member-list{
.list();
}
.member-list__item{
// write special rules
}
不过写的时候有点蛋疼，虽然有 Emmet 的支持。
不过这种方式是可以借鉴的，即使是使用最原始的方案，避免多级选择器，也是 CSS 编码的一个要求吧。
另外，对于机器生成的 DOM，将加上这样的写法，会更方便开发者编写 CSS 样式。
No more would I disparage a steam shovel for cleaning up a disaster site. I just wouldn’t use it to clean my room.
所以，面对不同需求，进而选取对应的解决方案。
没有「银弹」，也无需极端。
方案很多，要形成一个完整的团队方案并不是一朝一夕的事。不过，有些约定是可以统一的。
比如结构，对于所有的页面
@import "normalize.css"; // 统一不同浏览器间的基础样式
@import "common.css"; // 共有的样式，Grid System 等
@import "special.css"; // 仅当前页面
将公有的部分和特例严格分开，以最大化避免对兄弟页面的影响。
每一个 special 必须加上页面标记予以区分。
至于，其他的命名规则等，需要根据具体方案来使用。