“多类名”模式意味着，你只需要用一个单独的组件内部选择器，便可以改变所有类型的btn元素的样式。“单类名”模式意味着，你必须顾及所有可能的按钮类型，并在创造一个新的按钮变体时调整这个选择器。
结构化的类名
当创建一个组件时——并为之添加了“主题”——其中一些class被用来区分各个组件，一些class被当做组件的修改器，其它的class则被用来关联DOM节点，它们一起被包含在一个较大的抽象组件中。
很难去判断btn（组件）、btn-primary（修改器）、brn-group（组件）和btn-group-item（组件子对象）之间的关系，这是因为这些名字不能清晰地表现class的目的。没有一致的模式。
在过去的一年中，我一直在尝试命名模式，目的是能帮助我快速理解在一个DOM片段中节点的表象之间的关系，而不用为此来回切换HTML、CSS与JS文件拼凑网站的架构。这种模式主要受到BEM系统的命名方法的影响，但被改编成一种我认为更容易浏览的形式。
我将一些结构当做抽象的“模板”来处理，其它的则视为更清晰的组件（通常建立在“模板”上）。但是这种区分并非总是必要的。
这仅仅是我目前发现的一种有用的命名模式。命名模式可以采用任何形式。但这种命名模式的好处在于消除了模糊的类名，只依赖（单）连接符，或者下划线，或者是驼峰格式。
原始文件大小和HTTP压缩的注意事项
任何关于模块化与可扩展的CSS的讨论都会谈及对文件大小与“膨胀”的担心。Nicole Sullivan的言论中经常会提到文件大小的存储（以及维护改进），并提到了像Facebook这样的公司采用这种方法的经历。进一步的，我想我会分享我在预处理输出时的HTTP压缩效果，以及大量使用HTML类的一些事情。
当Twitter Bootstrap刚刚问世的时候，我重写了已编译的CSS，以便更好地与手动操作的文件比较大小。在最小化所有的文件之后，手动操作的CSS文件比预处理程序输出的小10%。但是当所有的文件都通过gzip压缩后，预处理程序输出的CSS文件比手动操作的小了5%。
这强调了比较HTTP压缩后文件大小的重要性，因为减少的文件大小并不能说明全部问题。它暗示了有经验的CSS开发者在用预处理程序时不必太过关注编译后的CSS中一定程度的重复，因为它将在HTTP压缩后变得更小。通过预处理程序处理更易于维护的CSS代码所带来的好处，要胜过关注原始CSS和压缩后输出的CSS的美观或文件大小。
