声明：本文译自 CSS Architecture 一文，thanks Philip Walton for sharing and translate permission。

对多数 Web 开发人员来说，精通 CSS 意味着你可以在代码中完美重现一个视觉模型。你不用表格，也尽少用图片 – 对此你感到自豪。如果你真的很擅长，则你会用最新、最好的技术，比如媒体查询，过渡和转换。对优秀的 CSS 开发人员来说，这些都是必须，但在评估个人技能时，CSS 仍有一个方面很少被提及。

有趣的是，对其他语言我们通常不会这样疏忽大意。一个 Rails 开发人员不会因为他的代码合规范就被认为优秀。这是底线。它首先要符合规范，然后才好基于它来做评价：代码可读性如何？是否易于修改或扩展？跟程序的其它部分解藕度如何？扩展性如何？

这些问题，在评估代码库其他部分时是理所当然要问的，CSS 也不应该例外。今天的 web 应用程序比以往任何时候都要大，一个不经认真思索的 CSS 架构会削弱开发能力。所以，现在是时候了，像评估程序其他部分那样去评估 CSS。可不能再事后再说，或都干脆撇为“设计师”的问题。

良好 CSS 架构的目标

在 CSS 社区，要就最佳实践取得一般共识可不容易。只要看看 Hacker News 上的评论及 CSS Lint 释出后开发者们的反应就应该很清楚，我们连最基本的、CSS 作者该的和不该的都没法有一致看法。

因此，我认为我们应该首先定义我们的目标，而不是我为自己的一套最佳做法铺陈论点。如果我们在目标上达成一致，那么我们就有望找出糟糕的 CSS，不是因为它打破我们先入为主的关于好的观念，而是它在阻碍开发进度。

我相信良好的 CSS 架构目标应该与所有优秀软件开发相同。我希望我的 CSS 是可预见的，可重复使用的，可维护且可扩展的。

可预见的

可预见的 CSS 意味着你的规则不会给你意外。当你添加或更新一条规则，它不应该影响到你没打算影响的网站部分。对较少更改的小网站，这不很重要，但对数十或数百页的大网站来说，可预见的 CSS 是一种必须。

可重复使用

CSS 规则应该是抽象的，足够的解藕，你可以从现有部分快速创建新组件，而不必重编码那些你已经解决的模式和问题。

可维护的

当需要在你的网站上添加、更新或重新安排新组件和特性时，我们不需要重构现有 CSS。添加 X 组件到页面中不应该破坏 Y 组件。

可扩展

随着你的网站规模和复杂度不断增长，它通常需要更多开发者来维护。可扩展的 CSS 意味着，不论是一个人还是一个大的工程团队，都可以轻松管理。这也意味着，你的网站 CSS 架构平易近人，而不是一条巨大的学习曲线。仅仅因为你是今天唯一接触 CSS 的开发者并不意味着明天还如此。

常见的不良做法

在我们了解良好 CSS 架构方法前，我觉得有必要先看看一些常见的不良做法，这对我们是有帮助的。通常只有通过反复的错误，我们才能开始拥抱其他方法。

下面的例子，其实是我写过的代码的概括，虽然技术上说没问题，但每一个都会导致灾难，让人头痛。这些模式过去一直让我陷入麻烦。尽管我意愿美好，并且承诺这一次一定会有所不同。

基于父元素来修改组件

互联网上，几乎每一个网站都会有一个视觉元素，每次出现都一个样，却总有一次例外。面对这种一次性时，几乎每一个新 CSS 开发人员（即使是有经验的）都用同样的处理方式。你为这一异类找到一个独有的父元素（或者你创建一个），然后写一个新规则来处理它。

.widget { background: yellow; border: 1px solid black; color: black; width: 50%; } #sidebar .widget { width: 200px; } body.homepage .widget { background: white; }

第一眼看去，这只是段相当无害的代码，且让我们按上面确立的目标检查一下它。

首先，例子中的窗口小部件不可预见。创建这些部件的开发人员期望它们看起来都是某个样子，然而当他在侧边栏或主页上使用时，却发现它不一样，尽管标记完全相同。

它也不好复用或扩展。如果其它页面上也需要它，而且跟主页上的样子一样，会怎样？又要添加新规则。

最后，它不易维护。如果小部件要重新设计，将要在好几个地方更新 CSS ，而且与上面的例子不同，这种反模式规则很少出现在一起。

想像一下，如果这种类型的代码是在任何其他语言中完成。基本上，你就是先定义一个类，然后在另一部分代码，取得类的定义，然后基于某一特定用途做些修改。这直接违反开放/闭合的软件开发原则：

软件实体（类，模块，函数等）应该开放可扩展，对修改闭合。

在这篇文章后面，我们将看看如何不依赖父选择符来修改组件。

过于复杂的选择器

互联网上不时就会出现一篇文章，展示 CSS 选择器的能力，并宣称，你可以不靠任何类或 ID 样式化整个网站。

虽然技术上确实如此，但随着我接触 CSS 越多，我会越远离复杂的选择器。选择器越复杂，它跟 HTML 耦合度越高。依托 HTML 标签和组合的确可以让你的 HTML 干干净净，但结果是你的 CSS 又臃肿又杂乱。

#main-nav ul li ul li div { } #content article h1:first-child { } #sidebar > div > h3 %2B p { }

所有上述例子逻辑上均合理。第一个可能是在样式化下拉菜单，第二个说的是文章主标题看起来应该跟所有其他 h1 元素不同，最后一个例子好像是给侧边栏部分的第一段落增加些额外间距。

如果这 HTML 永远不变，这种说法还有可取之处，但 HTML 一直不变本身就很不现实。复杂的选择器让人印象深刻，它们可以从 HTML 中分离出表现，但它们很少有助于实现我们的目标 – 良好 CSS 架构。

上面这些例子全是不能复用的。因为选择器指向的是标记中某一特殊地方，另一组件因为 HTML 结构不同，也就没法复用那些样式。举第一个选择器（下拉）为例，如果类似的下拉需要在不同页面出现，并且它还不在 #main-nav 元素里，我们该怎么办？你只能重建整个风格。

一旦 HTML 需要改变，这些选择器也难以预见到情况。想像一下，如果某个开发者想把第三个例子中的 div 标签改成 HTML5 的 section 标签，整条规则就废了。

因为这些选择器只有在 HTML 保持不变时方有效，他们显然不可维护、不可扩展。

在大型应用中，你需要权衡然后做出妥协。以保持 HTML “干净”的名，换来复杂选择器的脆弱，其实并不值得。

过于通用的类名称

创建可复用的视觉组件时，组件的子元素置入组件类名的域中是很通用的作法。例如：

<div> <h3>...</h3> <div> Lorem ipsum dolor sit amet, consectetur adipiscing elit. In condimentum justo et est dapibus sit amet euismod ligula ornare. Vivamus elementum accumsan dignissim. <button>Click Me!</button> </div> </div> .widget {} .widget .title {} .widget .contents {} .widget .action {}

我们的想法是，.title,.contents 及 .action 这些子元素类可以安全地样式化，而不必担心这些样式会溢出到任何其他同名类元素中。确实如此，但它同样不能阻止同类名的样式渗入。

在一个大项目中，像 .title 这样的类名会经常出现，可能是在另一个上下文，甚至自身中。如果这种情况发生，部件的标题就会跟预想的不同。

过于通用的类名会导致难以预测的 CSS。

让一个规则做太多事情