我们已经看到基于组件父元素之一修改组件的缺点，但这里需要说一下：修饰类可应用到任何地方。基于位置的覆写只能在特定位置使用。修饰类则可以根据你的需要任意使用。最后，修饰类在 HTML 中清楚表达了开发者的意图。基于位置的类却相反，如果开发者只是查看 HTML，则基于位置的类根本不可见，大大增加被忽略的概率。

按逻辑结构组织你的 CSS

Jonathan Snook 在他的优秀著作 SMACSS 里建议把 CSS 规则分为四个不同类别：基础，布局，模块，和状态。基础由重置规则和元素缺省值组成。布局用于定位跨站元素，还包含通用布局方式如网络系统。模块是可重复使用的视觉元素，状态则指可以通过 JavaScript 开启或关闭的样式。

在 SMACSS 系统中，模块（相当于我说的组件）包括 CSS 规则的绝大多数，因此我觉得常常有必要进一步分割，抽象到模板中。

组件是独立的视觉元素。模板却是构建使用的基础块。模板无法自代表，也很少描述外观和风格。相反，它们是单一，可重复的模式，可以放在一起，形成一个组件。

举个具体的例子，一个组件可能是一个模式对话框。对话框在头部可能有网站的背景渐变标识，围绕它可能有一个阴影，在右上角可能有一个关闭按钮，它可能被固定定位，水平和垂直均居中。这四种模式中的每一个都可能在整站中一次又一次地用到，这样你就不必每次都重新编写这些模式。他们都是模板，一起则构成组件。

我通常不在 HTML 中使用模板类，除非我有一个很好的理由。相反，我使用一个预处理器在组件定义中引入模板样式。我将在后面详细讨论我这样做的理由。

使用类来样式化并且只用来样式化

无论谁，如果在大型项目上工作过，就可能遇到一个 HTML 元素有这么一个类，类的目的完全未知。你想删除它，但你很犹豫，因为它可能有些你不知道的用处。这样的事一次又一次的发生，然后，随着时间推移，你的 HTML 中充满了不起任何作用的类，只因为团队成员都不敢删除它们。

问题就在于，前端 web 开发中，类通常都被赋予太多责任。他们样式化 HTML 元素，他们扮演 JavaScript 钩子，他们加入到 HTML 中用于功能检测，他们用于自动化测试等等。

这是问题。当类被应用程序的大部分用到，要想把它们从 HTML 中移除就会变得相当可怕。

然而，确立一个惯例就可以完全避免这个问题。在 HTML 中，当你看到一个类，你应该能够立即说出它的目的是什么。我的建议是给所有非样式化目的的类加上前缀。比如我用 .js-， 前缀表示用于 JavaScript 目的，.supports- 则表示 Modernizr 类。所有不带前缀的类用于样式且只用于样式。

这使得查找并移除未使用的类变得简单，就好像搜索样式表目录一样了。你甚至可以在 JavaScript 中自动完成这一过程，只要交叉引用 HTML 中的类与 document.styleSheets 对象的类。不在 document.styleSheets 中的类，可以安全删除。

总的来说，内容从表现区分开是最佳实践，功能跟表现分离同样重要。使用样式化的类做 JavaScript 勾子会高度藕合你的 CSS 和 JavaScript，结果会很难或不可能在不破坏功能的情况下更新某些元素的外观。

使用逻辑结构命名你的类

当下，大多数人写 CSS 用连字符分隔词。但单独的连字符通常并不足以区分不同类型的类。

Nicolas Gallagher 最近写了一篇，内容是他如何解决这个问题，我对他的办法略加修改然后应用，取得了不错的结果。为描述命名约定的必要，请看看以下：

/* A component */ .button-group { } /* A component modifier (modifying .button) */ .button-primary { } /* A component sub-object (lives within .button) */ .button-icon { } /* Is this a component class or a layout class? */ .header { }

如果只是看上面的类，很难区分它们分别应用于哪一类规则。这不仅增加开发过程中的混乱，也使得你很难自动化测试你的 CSS 和 HTML。一个结构化的命名惯例，让你看到一个类名就确切地知道它与其他类的关系以及它应该出现在 HTML 的哪里 – 也使得命名更容易，此前并不能的测试变得可行。

/* Templates Rules (using Sass placeholders) */ %template-name %template-name--modifier-name %template-name__sub-object %template-name__sub-object--modifier-name /* Component Rules */ .component-name .component-name--modifier-name .component-name__sub-object .component-name__sub-object--modifier-name /* Layout Rules */ .l-layout-method .grid /* State Rules */ .is-state-type /* Non-styled JavaScript Hooks */ .js-action-name

第一个例子重写：

/* A component */ .button-group { } /* A component modifier (modifying .button) */ .button--primary { } /* A component sub-object (lives within .button) */ .button__icon { } /* A layout class */ .l-header { } 工具

保持一个有效、有组织的 CSS 架构是非常困难的，尤其是在大型团队里。一些这或那的不良规则，可以越滚越大，直到变成一个不可收拾的烂摊子。一旦你的应用程序 CSS 进入特殊性战争的地步，并且只能靠着出 !important 这张王牌，它不从头开始也就基本无法恢复。关键是从一开始就要避免这些问题。

幸运的是，有一些工具可以让控制你的网站 CSS 架构变得简单。

预处理器

这些日子里，谈 CSS 工具而不提预处理器是不可能的，因此本文也不例外。但在我赞美它们的有用之前，我应提醒几句。

预处理器帮助你更快地编写 CSS，而不是更好。因为最终它被变成纯 CSS，应此也适用同样规则。既然预处理器能让你更快地写 CSS，那么它也可以让你更快地写糟糕的 CSS，所以在考虑一个预处理解决你的问题前，重要的是要先明白良好的 CSS 架构。

许多所谓的预处理器“特性”实际上对 CSS 架构非常不好。以下是一些“特性”，我尽可能要避免（虽然总体思路适用于所有预处理语言，以下这些指南特指 Sass）。

预处理器最好的部分，是一些函数如 和 。两者都能让你轻松管理 CSS 抽象，而不添加多余东西，也不会在你的 HTML 中添加大量基类，这些基类相当难管理。