如何写好CSS？（OOCSS\DRY\SMACSS）

我现在面对的CSS基本上就是一个三头六臂的怪物，一点不夸张，因为真的是三头六臂，同一个样式在同一个element上作用了好几遍，而同一个样式又分散在4，5个class上，优先级有很多层。可以看得出这个怪物不是一个人造就的，早期的开发者选择了SCSS技术，但混乱的import导致了一些基本的样式被多次调用，而后面的开发者又为了摆脱之前的混乱引入了其他共用样式，但无济于事。原因出在HTML上，CSS依托于HTML没有被正确的抽象，而HTML又完全的依赖业务，所有class以业务取名，HTML和CSS基本没有复用，最终抽出的共用样式也仅仅是又一次的重复。CSS重构最难的地方在于没有脚手架，即测试。虽然有一些方法来测试，比如reftest，但还不够成熟。抱着有总比没好的心态，CSS被一层又一层的覆盖了上去。

真正的问题是什么？

CSS即层叠样式表，所以一层一层覆盖其实是其本质特征。真正的问题在于维护，许多人认为CSS仅是样式，不是代码，无需维护，所以任意书写，只要将自己需要的样式的优先级设为最高即可，才导致了深层级CSS的出现，因为每次添加一个样式就必须比以前的优先级高才能在页面看到。深层级不仅造成维护性降低，可读性也是一个问题，人不是机器，无法很优雅的按优先级阅读，所以很难确认一个样式用于哪里，其实还存在许多的冗余样式，在任何地方都被覆盖的样式。这样的代码在扩展性上，一开始反而是有优势的，因为添加一个新class，无需担心影响其他地方，但慢慢随着项目规模的增大，页面增多，需要复制样式的地方也越来越多，它们之间又存在微小的差异，设计的更改，需求的变化，这一切都会将这种快餐式的CSS推进柏油坑。因为难以维护，所以无法响应需求，所以无法复用，只能复制，恶性循环。

正如上面所说的，问题在于可读性、维护性、扩展性、复用性这几个方面。所以只要提高它们就能解决问题, 虽然这么说，也不是如此简单的。先来谈谈在CSS中，这些概念都有着怎样的意义。

可读性

有人认为CSS不是程序，不需要可读性，有人认为CSS只要写出来就有可读性，因为很简单。抛开各种预处理器不说，原生CSS结构确实简单，没有需要编程的部分，但仍然可能导致混乱。原因有二，一是CSS可以层叠，其中涉及到了优先级和作用范围，如果写的不好，人很难读出其中的意义，二是CSS属性众多，加上CSS3引入了很多用法独特的属性，一个选择器可能包含几十个属性。比如下面这段我随便写的CSS代码：

span {
    -webkit-box-shadow: 6px 4px 4px red;
    -moz-box-shadow: 6px 4px 4px red;
    box-shadow: 6px 4px 4px red;
}
div span {
    border-width: 4px;
    border-style: dotted;
    border-color: blue;
}
#box {
    border-left: 2px solid red;
    border-bottom: 2px solid red;
}

乍一看也没什么，都是border，大致能看出来这段CSS只是为了添加一个红色的阴影让box看起来比较立体。但中间的部分似乎是捣乱的，你可能会说这太傻了，看不到吗。是的，当这3部分散落在上万行的CSS中时，肯定看不到。于是有人很自然的想起了我们可爱的浏览器，没错，在浏览器中可以快速找到作用于目标的CSS样式，但这也是万恶之源。首先我假设你不知道中间那部分东西是为了什么而写的，因为你是靠浏览器找到它的。然后剩下两种可能，不管三七二十一改了再说和看看它为什么存在。前者悲剧的可能性是100%，后者悲剧的可能性是90%，因为你已经掉坑里了，很快我们会发现要修改它还牵扯到了另外的地方，接着在浏览器中探索到另一个莫名其妙的样式，当你弄懂全部的时候，你应该已经把上万行的代码弄了个一清二楚了，也许最幸运的是，浪费了几个小时的时间发现只需要修改一行就能达到目的。

当然，我们可以天真的认为，只要把他们写在一起就可以了，这样找起来很简单。而我将继续顺着这样的思路来尝试曝露问题。

维护性

所谓物以类聚是很有道理的，人们习惯将事物归类，但问题是分类标准，样式并不关心业务，无论是什么文字内容，还是功能有何不同，它在乎的只是样式，比如文字的尺寸，间距和宽高，颜色等等。如果简单的将一个组件的样式放在一起，势必带来的就是小段代码的重复书写。不觉得有多严重？我来举个栗子。

aside {
    box-shadow: 6px 4px 4px #AA3343;
}
nav {
    box-shadow: 6px 4px 4px #AB3633;
}
.item {
    box-shadow: 6px 4px 4px #AA3732;
}
.item.otherStatus {
    box-shadow: 6px 4px 4px #AA3132;
}

继续说上面的例子，box需要阴影，但如果这个项目的UI统一风格，包括sidebar，navigator以及item都需要这样的阴影呢？再如果，明天客户或者UX一拍脑袋，这个阴影应该是灰色的不该是红色的呢？不要继续天真的认为全局替换是救命稻草。首先，没有几个网站会用red，blur做色调的，你用的应该是#AA3333，这样的代码，然后你发现sidebar用了#A43433，而navigator是#AB3633，等等，item有两个状态，而两个状态对应的颜色是不一样的。这怎么可能？但当你打开浏览器的时候你会发现本来就相差无几的颜色，在阴影中变得一模一样了，谁看的出来呢，当初使用的时候可能也不过是随意的在mockup中取的一个颜色。

大量的重复带来的不仅仅是代码的冗余，我们必须靠人力去同步它们，而人很难保证它们的修改是完全一致的，尤其是当它们中引入了一些不一致的独特的东西时。不要小看CSS，其后果就是进度和人力的压力，后面就是PM有没有读过《人月神话》的事了。

肯定有人在想，谁让你当初要写成这样呢。我们在读代码的时候最喜欢问，当初为什么要这么写？但慢慢的你会读出它的历史，有时候它是身不由己的。这就涉及到了下一个要讨论的内容。

扩展性

扩展性是一个具有欺骗性的东西，所谓的扩展性其实就是在现有基础上再次开发新东西的性能，但我认为它还必须有前提条件，那就是保持可读性与维护性。

简单的追求可维护性是自取灭亡，原因很简单，将新旧代码完全分离的时候扩展性最高，因为不必担心对以前的部分有影响，新的样式可以随意发挥。是不是很神奇，这样想的我们写下的代码，肯定就是前面我们追问的代码。所以自己回答自己吧，当初没考虑可读性和维护性，只想着快点增加新的样式，就这么写了。

那什么才是一个好的扩展性呢，简单来说，就是多功能产品。比如一个box，也许它的样式就时

复用性

似乎我一直在说的就是重复，那我们就来说说复用性，如何才能复用CSS代码是一个很大的问题，比如粒度，是一两个属性进行复用还是一大组选择器进行复用呢，再比如对象，是为了class复用属性，还是为了html复用class呢。这些选择不算太重要，但是带来的影响却很重大，可以说是整个CSS结构的改变。下面继续用box的阴影来讨论复用。

.shadow {
    -webkit-box-shadow: 6px 4px 4px #A93334;
    -moz-box-shadow: 6px 4px 4px #A93334;
    box-shadow: 6px 4px 4px #A93334;
    border-left: 2px solid #A93334\9;
    border-bottom: 2px solid #A93334\9;
}

这样看起来我有了一个shadow的class可以给任意的目标加上这个阴影了，但这导致了一个复用的问题，和上面那段捣乱的CSS样式一样，如果item已有另外2个border了，那这个class是无法去除的。所以复用时不仅要考虑需要什么，还要考虑不需要什么。另外一些必须的属性比如display还有overflow等也是要考虑的，因为user agent的原因，很多属性是隐藏在element中的。

如何解决问题？

主流的CSS原则有OOCSS，DRY，SMACSS以及BEM，他们皆是为解决CSS的各种问题而生。

OOCSS

OOCSS即面向对象的CSS，这里对象指的是页面中的元素对象，与传统编程中的面向对象不太相同，比如不存在方法这种东西，硬要说的话，附加的一些class可以看作是继承或者接口之类的东西来实现对象的差异化。比如电商网站中的商品就是一个典型的对象，它们既有许多相同的部分，又有许多差异，宽高、按钮、图片、标题等基本布局都是相同的，而边距、线框、背景颜色、字号等都是差异化的。由此按照OOCSS的指导原则，我们应该写一个product
class，然后为其添加一些border、theme之类的class来差异化它：

.product {
    display: block;
    overflow: hidden;
    float: left;
    width: 200px;
    height: auto;
}
.product-head{...}
.product-body{...}
.product-foot{...}

.product-theme-black {
    background: black;
    color: white;
}

.product-border {
    border: 1px solid #333;
}

这样在以上两种附加class的作用下，我们在html中就可以获得4种不同的product样式，随着附加class增加，product的样式也会呈指数增加，千变万化。这仅仅是一个简单的例子，意在点出OOCSS的理念，但并没有突出它的意义所在。别着急，先来看看OOCSS的两大原则。

1. 分离容器与内容

所谓的容器即包裹对象的元素，比如一个div，我们经常会命名为wrap、container、body等。那么如何才算是分离容器与内容呢？很简单，一句话，内容在哪都可用。也就是说不应该出现这样的情况：

.container .product {
    ...
}

这样干的结果就是复用性大大降低，因为只能在这个容器内使用它了。但这并不代表我们应该将所需的样式全部一股脑的扔进单独的class中，对于差异化应该单独放在一个class中，这才是OOCSS的精髓。

举个例子，当我们既不想牺牲太多性能，又想来个瀑布流显摆显摆的时候，大部分前端都会使用column，类似泳道的设计。你想说哦不，这是伪pinterest，但是谁在乎呢，用户是不会有闲工夫拖拽浏览器的宽度来鉴别它的，在IE下商品多的时候至少不会太卡。哈，别较真，首先分为几个column，然后按照高度往里填放商品，先来看看下面的代码吧，我有省略一些样式避免误导：

.column {
    height: auto;
    width: 200px;
}

.product {
    width: 180px;
    margin-right: 20px;
    margin-bottom: 10px;
}

看起来不错，每列200px宽，商品放入其中，水平间距要大，垂直间距要小些才像column。但是等等，我们总还是需要整齐摆放的商品列表的对不对。也许margin并不是product的必要属性，至少它应该是可变的。我们抽出它来：

.product {
    width: 180px;
}

.vertical-product {
    height: 400px;
    margin-right: 10px;
    margin-bottom: 10px;
}

.horizontal-product {
    height: auto;
    margin-right: 20px;
    margin-bottom: 10px;
}

这样便将column或list之类的容器与product分开来毫无关系了，即使以后出现了其他组织形式，只要product的基本结构没有变都可以直接复用，无非是添加一些附属样式到新的xxx-product的class中。另外这样做还有一个好处，设计逻辑放在了HTML中，CSS更加强大。

什么是样式逻辑？商品在瀑布流中不定高，在列表中定高，这就是一种样式的逻辑，如果用父子选择器的形式写在CSS中，那它就失去了自由。而放在HTML通过选择添加何种附属class来展现不同形式的product，则非常的自由与灵活。另外值得一说的是，margin-bottom是一样的，但我们应该各自放在各自的class里面，原因很简单，它们仅仅是一不小心恰好一样，在设计逻辑中它们并不是一样的bottom，这里并不是重复，而是看起来一样。如果以后需要改变其中的一个bottom，共用则显得非常别扭。

2. 分离皮肤与结构

第二点很容易理解，皮肤（theme）就是视觉效果，即使被剔除网页也没有什么影响的就是皮肤；而结构指地并不是像HTML这样抽象的结构，因为CSS毕竟还是样式，所以结构只是相对的页面结构。

先来看看我们的product吧，添加一些背景色和边框：

.product {
    width: 200px;
    background: #F6F2F2;
    border: 1px solid #C4A0A0;
}

看起来还不错，不过设计师都是自大狂，精心的调色，完美的搭配，绝对不会让你仅仅使用这么一次的，页面的其他模块、sidebar甚至是header都可能采用相同的背景颜色与边框，它们甚至可能互相嵌套。好吧，这其实在设计上是为了视觉统一，毕竟没有几个设计大师能hold住3，4种以上的颜色。所以我们能做的并不是在每个class中添加这样的样式，而是把它提出来成为独立的class，原因就像我开篇说的那样，颜色为混沌之源。

.main-bg {
    background: #F6F2F2;
}

.main-border {
    border: 1px solid #C4A0A0;
}

这样就可以在页面中随时使用主要的设计元素了，而且需要修改时也非常的简单，不用担心有什么地方漏掉。另外我将背景与边框分为了两个class，原因还是设计逻辑应该放在HTML，背景与边框并不是一定同时出现的，两者的关系应该由HTML决定，即使设计上逻辑决定了两者的绑定，在实现时也有可能因为HTML结构而放在两个不同的元素上。

OOCSS强调class，将每组样式写成一个class方便HTML中使用，众多class组合起来能千变万化组成一个对象。所以如果是想一劳永逸的写一套UI作为开发时使用的样式，我建议使用OOCSS来进行开发。但它也有缺点，过多的将设计逻辑放在HTML中，极大的自由化了页面开发时的选择，如果写HTML的开发者不能很好的理解整套CSS的结构，较易在HTML中造成class混乱。

DRY CSS

DRY就是Donot repeat youself 不要重复。但其实这个名字有点无趣，哪个理论不是消除重复呢，但如何消除才是意义所在。总的来说我认为DRYCSS与OOCSS是两个极端，所以我将会以对比的方式来讲讲DRYCSS的内容。使用DRYCSS很简单，三步。

1. 分组可复用属性

DRYCSS跟OOCSS有点像，第一步都是分组样式，消除重复，但就像我说的，关键在于如何。OOCSS将样式集合看作对象，所以分组的逻辑是，某个元素本身应该是什么样的，而DRYCSS则关注重复，无论什么逻辑，只要是一样的就应该只有一个。其中粒度是值得思考的问题，如果太细，那只会成为一行样式一组这样无意义的情况，如果太粗，又会变成毫无复用性的庞然大物。我认为可以将一些有关联的缺了A时B就没作用的样式分为一组，还可以将某些惯用搭配分为一组。下面举个例子：

{
    float: left;
    position: absolute;
    display: inline-block;
    overflow: hidden;
}

这是一组样式，可用来触发Block formatting Contexts（块级格式化上下文），如此就完成了一组样式。接着再写2组关于尺寸的样式吧。

{
    width: 960px;
    height: auto;
}
{
    width: 720px;
    height: 600px;
}
{
    width: 220px;
    height: 600px;
}

这是三组样式用来布局，将页面分为左右两部分。

2. 按逻辑为分组命名

接着我们来为其命名，其实就是添加一个ID选择器，但是我们并不真的使用它，而是用来标示该组样式。下面就来命名上面所分组的样式。

#BLOCK_FORMATTING_CONTEXTS
{
    float: left;
    position: absolute;
    display: inline-block;
    overflow: hidden;
}

#LAYOUT_FULL
{
    width: 960px;
    height: auto;
}

#LAYOUT_CONTENT
{
    width: 720px;
    height: 600px;
}

#LAYOUT_SIDEBAR
{
    width: 220px;
    height: 600px;
}

这一步类似OOCSS的class，它决定了每组样式所代表的逻辑或用途，然而DRYCSS多了最关键的下一步，也是与OOCSS本质区别。

3. 为各个分组添加选择器

DRYCSS在使用时和OOCSS有着巨大的差异，在CSS文件中写入HTML中的class选择器来使用这些分组后的样式，而不是直接在HTML中使用CSS文件中写好的class。

.header,
.container,
.content-right,
.content-left,
#BLOCK_FORMATTING_CONTEXTS
{
    float: left;
    position: absolute;
    display: inline-block;
    overflow: hidden;
}

.header,
.navigator,
.container,
#LAYOUT_FULL
{
    width: 960px;
    height: auto;
}

.content-right,
.section,
#LAYOUT_CONTENT
{
    width: 720px;
    height: 600px;
}

.content-right,
.sidebar,
.profile,
#LAYOUT_SIDEBAR
{
    width: 220px;
    height: 600px;
}

可以看到，使用DRYCSS时，在HTML中所写的class将会非常表意，元素本身是什么用来做什么，就使用其意义的class命名，而且基本上是一个元素对应一个class，HTML将变的简单明了。另外DRYCSS也是相对于OOCSS的一种逆向思维，这才是最有趣的地方。在开发中，不应该像OOCSS那样思考如何应对未来假象的HTML，而是仅仅思考CSS本身。

总的来说，OOCSS适合开发CSS框架或整套UI模版，是自外向内的UI开发方式；而DRYCSS则适合拯救混沌的HTML，或者加强HTML的结构性和表意性，是自内向外的UI开发方式。这里的内指地是HTML结构，外指地是CSS样式。

SMACSS

这是一个相对繁杂的CSS理论，分为Base、Layout、Module、Status和Theme共五个部分。不过它的核心思想仍然和OOCSS类似，鼓励使用class。

1. Base 基本属性

基础属性很容易理解，就是最基本的东西，很多样式简单的网站都采用一个简单的二级CSS文件模式，一个base.css通用于所有页面，而每个页面有一个特定的CSS文件，我想这就是Base的雏形。要说具体是什么，比如reset文件，再比如放置clearfix或BFC的一些类似工具集的文件。

其实最终会发现，在Base中的CSS属性将会是几乎全站都要用到的属性，但我不想这么描述Base，因为这会误导人。大多数情况下，在一个网站建立之初也只会有几个简单的页面，于是这几个页面都要用到的属性就变成了通用属性，但并不是这么简单的。随着网站规模的扩大，需求的增加，设计师们灵感的迸发，所谓的通用和统一也在发生着潜移默化。所以在编写Base时，应该遵循的基准是，哪些样式是你做下一个网站时也会想用的，哪些样式即使设计改变了也只需要改变一些数值和颜色，哪些样式是一些基本原则；而不应该将目前大部分页面都在使用的样式放在Base中，还是那个道理，它们也许仅仅是恰好相同，而非逻辑一致。

2. Layout 布局

布局是一个网站的基本，无论是左右还是居中，甚至其他什么布局，要实现页面的基本浏览功能，布局必不可少。SMACSS将这一功能单独提出也是非常正确的，另外还约定了一个前缀l-/layout-来标识布局的class。举个最普遍的例子。

.l-header {}
    .l-brand {}
    .l-navigator {}
.l-container {}
    .l-sidebar {}
    .l-content {}
.l-footer {}

这就是一个简单的左右布局，导航和Logo中规中矩在最顶部。

3. Module 模块

模块是SMACSS最基本的思想，同时也是大部分CSS理论的基本，将样式模块化就能达到复用和可维护的目的，但是SMACSS提出了更具体的模块化方案。首先表象上来看，SMACSS中的模块应该拥有一个名字，并且为其class名，而模块其他class皆以为前缀。比如：

.product {}
    .product-title {}
    .product-image {}
    .product-border {}
    .product-shadow {}

可以看到例子中product是一个模块，title和image是包含在模块内的组件，可用可不用；border和shadow是类似OOCSS的附加class用来改变模块本身。总之，在模块内可以使用其名称做前缀任意组织模块结构，但目前是让其变得更易用，提高可扩展性和灵活度，如果仅仅为了某些功能而特意写一些class就有点有形无实的感觉了。

4. State 状态

状态经常和JavaScript放在一起使用，它是一种用来标识页面状态的class，无论是为用户标识还是用程序标识。还是一个常见的例子，马上就明白。active经常用来表示当前的tab，或者当前选中的目标，这就是一种状态，无论是样式还是程序都需要知道它。

SMACSS仍然有一个对应的前缀用于标示状态class，is-是一个合适的词，指明某一元素是什么状态。

5. Theme 主题

主题就是皮肤，和OOCSS的分离皮肤与结构不谋而合。更重要的是对于可更换皮肤的站点来说，这样的分离是非常必要的，只需要更换加载的theme文件即可将皮肤更换。

总的来说，SMACSS是一个较为注意细节与实现的CSS理论，非常适合初涉CSS的人，它可以让你的CSS跑在轨道上而不至于脱轨。其思想也与OOCSS有很多相通之处，如果没有适合的方案，我建议新手可以适当的融入OOCSS的思想而使用SMACSS的结构，这样写出来的网站样式至少不会马上陷入泥沼。

哪一个好用呢？

谈了许多的CSS原理，已经有点眼花缭乱，到底哪个好呢？这个问题又归结到了最佳实践上，虽然我并不认为有这样的实践，但我认为一个项目一定会有适合的实践，比如前面说的，如果你想做一个CSS框架然后再写HTML，那就用OOCSS；如果你想先写HTML或者已经有一个旧的页面，那DRYCSS应该很适合你；如果新手不知如何下手，那SMACSS可以指导你入门。

无论如何，在我过去很长一段时间的独立UI开发“生涯”中，这些情况我都遇到过，也有一些自己的想法，我想我将在下一篇博客中谈谈自己对CSS的理解，并尝试整理出一些类似理论的东西来。