正如我们看到的，基于父元素的缺点对组件进行修改，需要重申：一个修饰符类可以在任何地方使用。基于位置的覆盖只能被用在一个特定的位置，修饰符类也可以根据需要被多次使用。显然，修饰符类是符合HTML开发者需求的。

　　把CSS组织成逻辑结构

　　Jonathan Snook在其非常优秀的《SMACSS》书中提到，CSS可以被分成四个不同的类：基础（base）、布局（layout）、模块（modules）和状态（state）。基础包括了复位原则和元素缺省值；布局是对站点范围内的元素进行定位以及像网格系统那样作为一种通用布局助手；模块即是可重用的视觉元素；状态即指样式，可以通过JavaScript进行开启或关闭。

　　组件是一个独立的视觉元素。模板在另一方面则是构建块。模板很少独自站在自己的角度去描述视觉和感觉，相反，它们是单一的、可重用的模式，可以放在一起形成组件。

　　为了提供更详细的例子，一个组件可能就是一个模式对话框。该模式可能在头部包含渐变的网站签名、或者在周围会有阴影、在右上角会有关闭按钮、位置固定在垂直与水平线中间。这四个模式可能被网站重复多次使用，所以在每次使用的时候，你都很少会想到重新编码与设计。这些所有的模板即形成了一个模块组件。

　　因样式和风格使用类

　　有过大型网站建设的人可能有个这样的经验，一个拥有类的HTML元素可能完全不知道其用途。你想删除它，但是又犹豫不决，因为它的作用你可能还未意识到。一旦这样的事情一遍又一遍发生的时候，随着时间的推移，项目中将会有越来越多这样的类，只因为团队成员都不敢删除。

　　在Web前端开发中，类承担了太多的责任，因此才会产生这样的问题。样式化HTML元素、扮演着JavaScript hook角色、功能检测、自动化测试等。当这么多应用程序在使用类时，让你从HTML中删除它们将会变的非常艰难。

　　然而，使用一些成熟的约定（惯例）即可完全避免这种问题。当在HTML中看到一个类时，你应该立即明白它的目的。我建议在前面使用前缀，例如用于JavaScript的在前面加.js，表示Modernizr classes可以在前面加.supports，没有加前缀的即用于表示样式。

　　这样来发现未使用的类和从HTML中移除它们将会变得非常简单。你甚至可以自动完成这一个过程，在JavaScript中通过交叉引用HTML中的document.styleSheets对象。如果在document.styleSheets中没有发现该类，即可安全移除。

　　一般来说，最佳做法是把内容与演示相分离，另外把功能分离开来也同样重要。使用样式类像JavaScript hook在某种程度上可以加深CSS与JavaScript之间的耦合，但在不打破功能性的前提下很难或者根本不可能更改外观。

　　有逻辑的命名类

　　大多数写CSS的人喜欢使用连字符来分隔命名词，但连字符并不足以区分不同类型之间的类。

　　Nicolas Gallagher最近针对遇到的问题写了一个解决方案，并且取得了巨大的成功（略有改动），为了说明命名约定，可以考虑以下格式：

1234567891011/* 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中的位置——使命名更加简单和容易测试。

123456789101112131415161718192021/* 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

　　重做第一个例子：

1234567891011/* 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 { }

　　6.工具

　　维护一个高效且组织良好的CSS架构是非常困难的，尤其是在大型团队中。下面向大家推荐几款很好的工具来帮你管理网站CSS架构。

　　CSS Preprocessor

　　CSS预处理器采用PHP5编写，有预处理器的常见功能，可以帮你快速编写CSS。另外有些号称“功能”的预处理器实际上并不会对CSS架构产生良好作用。下面我提供一个列表，在使用时一定要避免：

　　● 切勿纯粹为了组织代码来嵌套规则。只有当输出你真正想要的CSS时才可以。

　　●在无需传递参数的时候切勿使用mixin，不带参数的mixin更适合用作模板，易扩展。

　　●切勿在选择器上使用@extend，它不是个单一的类。从设计角度来看是毫无意义的，它会膨胀编译过的CSS。

　　●在运用组件修饰符规则时，切勿使用@extend UI组件，这样会失去基础链。

　　@extend和%placeholder是预处理器里面非常好的两个功能。它们可以帮你轻松管理CSS抽象并且无需添加bloat和大量的基类到CSS和HTML里，否则将会很难管理。

　　当你初次使用@extend时，常会与修饰符类一起使用，例如：

123456789.button {    /* button styles */}   /* Bad */.button--primary {    @extend .button;    /* modification styles */}

　　这样做会让你在HTML中失去继承链。很难使用JavaScript选择所有的按钮实例。

　　作为一般规则，很少去扩展UI组件或者在知道类型后做些什么。这是区分模板和组件的一种方式，模板无需参与到应用程序的逻辑，并且可以使用预处理器进行安全扩展。

　　下面是一个引用上面的模式例子：