CSS架构目标：预测、重用、扩展、维护(3)_H5之家

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

因样式和风格使用类

有过大型网站建设的人可能有个这样的经验，一个拥有类的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最近针对遇到的问题写了一个解决方案，并且取得了巨大的成功（略有改动），为了说明命名约定，可以考虑以下格式：

1./* A component */ 2..button-group { } 3. 4./* A component modifier (modifying .button) */ 5..button-primary { } 6. 7./* A component sub-object (lives within .button) */ 8..button-icon { } 9. 10./* Is this a component class or a layout class? */ 11..header { }

从上述类中可以发现其很难正确区分类型规则。这不但会困惑，而且连自动测试CSS和HTML也变的很难。一个结构化的命名约定应该是初看就能够知道其类名与其他类之间的关系，并且知道它出现在HTML中的位置——使命名更加简单和容易测试。

1./* Templates Rules (using Sass placeholders) */ 2.%template-name 3.%template-name--modifier-name 4.%template-name__sub-object 5.%template-name__sub-object--modifier-name 6. 7./* Component Rules */ 8..component-name 9..component-name--modifier-name 10..component-name__sub-object 11..component-name__sub-object--modifier-name 12. 13./* Layout Rules */ 14..l-layout-method 15..grid 16. 17./* State Rules */ 18..is-state-type 19. 20./* Non-styled JavaScript Hooks */ 21..js-action-name

重做第一个例子：

1./* A component */ 2..button-group { } 3. 4./* A component modifier (modifying .button) */ 5..button--primary { } 6. 7./* A component sub-object (lives within .button) */ 8..button__icon { } 9. 10./* A layout class */ 11..l-header { }

6.工具

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

CSS Preprocessor

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

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

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

1..button { 2. /* button styles */ 3.} 4. 5./* Bad */ 6..button--primary { 7. @extend .button; 8. /* modification styles */ 9.}

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

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

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

1..modal { 2. @extend %dialog; 3. @extend %drop-shadow; 4. @extend %statically-centered; 5. /* other modal styles */ 6.} 7. 8..modal__close { 9. @extend %dialog__close; 10. /* other close button styles */ 11.} 12. 13..modal__header { 14. @extend %background-gradient; 15. /* other modal header styles */ 16.}

CSS Lint

CSS Lint是由Nicole Sullivan和Nicholas Zakas编写的一款代码质量检测工具，帮助CSS开发人员写出更好的代码。他们的网站上是这样介绍CSS Lint的：

CSS Lint是一个用来帮你找出CSS代码中问题的工具，它可做基本的语法检查以及使用一套预设的规则来检查代码中的问题，规则是可以扩展的。

使用CSS Lint建议：

总结

CSS不仅仅是视觉设计，也不要因为你编写CSS就随便抛出编程的最佳实践。像OOP、DRY、打开/闭合、与内容分离等这些规则应该应用到CSS里面。无论你如何组织代码，都要确保方法真正帮助到你，并且使你的开发更加容易和可维护的。