本文转载自：众成翻译译者：dreamforker链接：http://www.zcfy.cc/article/785原文：https://medium.com/peergrade-io/structuring-css-in-large-projects-37f1695f5ec8#.wyys1qbhg
写CSS很容易。 写持续可维护的CSS则很难。
你也许听说过不下100次了。因为在CSS中默认都是全局的申明。如果你是个写C的程序员你知道全局变量是糟糕的。如果你是程序员你会知道，独立及可组合的模块是一个可维护系统的关键所在。
已经有很多CSS指南帮助人们构建可维护的CSS： SMACSS, OOCSS, BEM, ITCSS, ACSS, CCSS, Atomic Design, Maintanable CSS, rscss, 也许更多.
然而CSS的问题在哪里呢？
span {
font-size: 11px;
}
.header-right {
font-size: 22px;
text-align: right;
}
如上的CSS定义， 样式立即生效于全局，并且影响到引用到此段代码的所有页面。 这里没有封装，没有独立的模块。
在一个标准的程序语言中， 仅为需要实现的方法引入需要的模块即可，例：
# Python modules
import requests
from Flask import url_for
// Node modules
var express = require(‘express’)
这样就知道引入模块将会怎样影响到你的代码，且引用的资源会明确影响到你正在实现的功能。
在CSS中这种角色是相反的。每次我写一行CSS时，会潜在地影响到项目中所有的东西，并且无意中改变了我当前工作以外其它页面的展现。 我的样式不仅仅是外泄， 它们像洪水般涌进我应用中的所有角落和缝隙。
现在这就变得好理解了，那些基本排版、文本输入框以及全局继承的样式就显得合理了。这是HTML和CSS为何被构建出来根本原因。这些语言工具是公开创建的。 想理解这些语言背后的原因，我常想去排版一本书：想每页看起来是类似的， 想一个简单连贯的样式贯穿始终但不需要那些冗余的CSS代码。那就是为何<h1-6>,<section>等标签合理存在的原因，并且始终能影响全局的样式。
然而，世界已经变化，Web也已经变化。 我们不再构建 Web 页面，我们开始创建Web应用。我们今天不再需要从Web上请求很多资源，到处都是已经内建好的HTML和CSS公共模块。
事实上这些谓之为一个 特定样式的新方式，也可能是一个构建web的新方式。但是如今，我们已经被CSS和HTML纠结良久，那意味着我们要小心翼翼的去用那些工具制作可管理和可维护的Web应用。
Peergrade.io处理CSS的方式
规则1: 使用前缀 (class类名)
在Peergrade.io中我们在所有样式名中使用前缀 .pg。 在你的CSS代码中如果不使用前缀可能会带来些麻烦。原因是无前缀的类名最终将会导致和引入的样式冲突。例如你需要一个选色器datepicker - 你绝对不希望胡乱拼凑的去构建它（至少我不希望如此！），所以你引用了这个组件。 现在你可能在你的样式中随处可见类似 .prev, .next和.separator等的类名， 如果你不用前缀它们可能会和你的类名有潜在的冲突。
在很长一段时间内字体是不会在类名中用前缀的， 那意味着你经常会遇到.icon-***之类为前缀的命名冲突（现在他们用 **.fa前缀）。我们仍然拥戴作者Mark Otto，虽然我们对他无后缀名的Bootstrap有一点失望。
规则2: 不要嵌套CSS选择器
在Peergrade.io中用到了Sass。 用Sass时，Sass本身有能够快速和HTML匹配的模式，例如：
#user-profile-page
.profile-description
h3
ul
li
a
过不了多久你会意识到 - 它其实很不友好。当你写它的时候，你也许会想这里仅有一个.profile-description的列表命名，但一两个月后， 你必须要增改另一个列表时，混乱的结构已经超出你想到的范围。
同样，可以在父元素内的子元素中独立定义样式 - 这并不会受到你在Sass这一层已经定义好样式的影响。
你可以通过subtle和 brittle ways在CSS中通过做选择器的嵌套来绑定你的HTML结构。
规则3: 构建组件时用边界元法（BEM）命名
尽可能试着用BEM命名去创建独立的组件，我们不必完全按照BEM的规范 - 只是命名组合，这意味着类名以如下的方式命名：
.block__element--modifier
为了达到这些我们按照如下构建Sass：
.pg-deadline
&__date
// becomes `.pg-deadline__date`
color: $color-gray
&__header
// becomes `.pg-deadline__header`
font-weight: 700
&--highlight
// becomes `.pg-deadline__header--highlight`
color: $color-green
如下我们用Sass嵌套去创建BEM类名命名方式。多少有点违背常理， 这实际会产生大量的扁平化CSS结构 - 没有嵌套 - 仅仅只有头部的类名定义。
如规则2预期我同样可允许.block--modifier方式的类名：
.pg-deadline--editable
.pg-deadline__header
background-color: $color-blue
.pg-deadline__date
color: $color-black
在这个特殊例子中我们允许一层的CSS选择器嵌套。 这允许我们仅可以修改在特定块（block）级别的修饰符， 并且在子块中不能重复修饰符（“E”在BEM中即元素elements）。
为了更好的理解BEM体系，可以转向这里 - 由Harry Roberts写的CSS指南 ：BEM形式的命名。（事后我们碰到类似的CSS时，自然会提及到Harry的这个命名体系）
向前看
看来没有人真正找到CSS最好的解决方案， 并且当看到Hacker News最新文章后， 相比较现状，我多少会有些失望。
归根结底：我们相信我们找到了一个CSS的可持续发展的根本， - 当然有更多改善的空间。 这计划就是去经常检查我们的指南书，去看看任务是否如我们所期望的那样去执行， 是否有必要去修正。
我们收藏的一些CSS参考
- Harry Roberts’ CSS指南书
- CSS魔法博客 (同样是 Harry Roberts的)
- 可维护的CSS框架
- https://philipwalton.com/articles/side-effects-in-css/