几个月前，我读了一篇文章article by Harry Roberts ，在文章里Harry Roberts 介绍了关于CSS一个有趣的概念。 他认为在css属性中使用[]，可以帮助开发人员快速理解这些属性的功能。 他给出了下面的示例，证明使用[]可以使类更容易校验-更容易快速理解。
我必须承认，我对这种手法感觉非常不舒服。 类的名称如果含有[或者]，没有css会与之匹配，因为它与css的一个属性重复，这看起来只是为人设计的而不是为浏览器。 事实上，到现在我还是反对这种手法，不过这使我更深入的理解标记和语义的概念，谢谢Harry！ 当我深入研究标记和语义时，一些朋友给了我类似的建议，如使用 / (Ben Everard)，或者 | (Stephen Nolan)，但是不舒服的感觉使我拒绝了他们的建议。 我想： 已经有很类了，为什么还要使用更多的类来使这些代码变得可读？ 这是疯狂的行为。 写出易读懂、易校验的html代码是一个值得追求的目标，但是上面这些设计手法违背了html中一些基础的设计思想。 更多 vs 更少 - 简单比较神奇的是，虽然在标签里面放那么多类让我非常不爽，可是人们爱哈利，因为他太特么能说了。提倡的某些东西，比如说 OOCSS 和单一责任原则，从我自己创建的一系列日益复杂的网站来看，我可以说这确实值得对样式行为进行解耦，不过直到最近我才找到一种让我觉得满意的方式来实现它。 我原先有做过一个 BEM 的版本，它强调了独立高于重用 ‐ 每个新的块默认是没有样式继承的，允许组件独立开发并且可以避免打乱页面其它样式的风险。不过代价就是碎片化(fragmentation) ‐ 忽然你会发现你有了 10 种不同的样式链接，12 种不同的蓝色，18 种差别细小的按钮样式等。妮可・沙利文，OOCSS 的作者，去年在墨尔本做了一个超赞的演示，讲到了这个问题是有多普遍，以及怎么解决它。 对我来说，我觉得可以接受的解决方案是，深入 CSS 的预处理机能，从而取得 BEM 的独立性以及 OOCSS 的一致性。比如说，下面这样的:
应该改成这样:
我成功终结了充满了占位符的文件，比如满眼都是那些_typography.scss 和 _brand.scss，这不但让我有能力控制碎片化，同时还能默认保持了样式的对每个新组件的独立性。所有的东西都挺好的，起码有那么一段时间是这样。 修饰符: M 是怎样破坏 BEM 的只要你做关于 CSS 类的命名 & 维护方面的任何研究，你一定会要看到尼古拉斯・加拉格尔的杰作"关于 HTML 的语义和前端架构"。其中一部分特别吸引我，他称之为修饰符的 '单类模式' vs '多类模式'。简单的说，你的 HTML 会有两个版本，看起来像这样:
这通过两个备选的 CSS 模式实现:
这两个模式的差别在于 btn--large 是否只要它自己就足够了，还是说它需要依赖类 btn 。单类模式说”可以”，它看起来更简单而且可以避免有人忘记把 btn 包含进来的情况。而且它也不啰嗦，配合 SASS 的 @extend 方法，它对 CSS 来说不像一个负担，只不过它有一个致命伤。 上下文重写我们假设你的所有按钮都有背景色，除了你顶部导航栏那些没有。在多类模式下，所有的按钮，大的小的，圆的方的，等等之类，都会包含类 btn，所以你可以这样写:
而在单类模式中，我们不知道哪种按钮会被重写，所以你只好这样:
很显然，这不理想 - 追加一个按钮变体也就意味着要检查所有地方的按钮样式重写以及添加一个新类。这是个大忌，所以许多人的讨论都回归到了多类模式上(尼古拉斯・加拉格尔, 本・史密西特)。我还看到一些别的方案，比如说汤米・马歇尔还有本・文思，他们用属性前缀选择器 ^=，可以检查你的属性是否以特殊字符串开头，比如:
这实现了单类模式下的简单的上下文重写，不过它还是太弱了，不是一个可以托付的选择。最致命的是，如果另一个类在 btn--large 出现，而且前缀选择器还没匹配到它，那么之后的所有的都完蛋了。而且，它还没有显式的方法来指定多个变种，比如说 btn--large--rounded。 我很欣赏这种创造性的方式，不过还是死路一条。好吧，到这里我特么操蛋了，吐，直到忽然某天我灵光一闪。 为毛要用类?不要在意我那么直接这种小问题，不过给我个理由先，为什么类是我们放样式信息的唯一位置？HTML生存守则如是说:
所以对吧，我们用类来描述"内容的属性性质"是很有道理的，但是好像我们对类需求过度了吧。一个属性就包括了所有的东西，从巨大的 BEM-风格 命名，比如说 primary-nav__sub-nav--current 到像 u-textTruncate 或者 left 或者 clearfix，到 JavaScript 用的比如说 js-whatevs，然后我们花了巨多时间来解决命名冲突的问题，然后还希望他们有很好的可读性。 通过约定 & 习惯这是可控的，而且还有像文章前面说到的哈利的那种技术也挺有用的，不过，有一个事实是，我们所有的操作都是基于一个全局命名空间(global namespace)的，不管有多少规约都无法改变的事实。这让我们下面出场的 AM 就有那么一点不同了。 在我们正式开始讨论它之前，我们来复习一下 CSS 一个鲜为人知的特点。 欢迎 ~= 登场，神奇的选择器从 IE7 开始，浏览器开始支持一种超厉害的 CSS 规则，叫做空格分隔属性选择器(space-separated attribute selector)， 具体描述在CSS技巧里面。它可以匹配任何属性值，通过空格分隔，就像它们是类一样。下面两行的 CSS 是等价的:
和 <div class='a b c'> 一样，它不在意 a,b 和 c 的顺序，也不在意是不是还有其它， ~= 选择器也不在意。不过 ~= 不限于类(class)属性，这就是这种全新技术的关键。 属性模块(Attribute Modules)属性模块，或者叫 AM，它的核心是如何为你的样式定义命名空间。让我们从一个简单的例子开始，一个网格，首先用类的方式描述:
好了，然后我们用属性模块方式来做。我们有两个模块，行(rows) 和 列(columns) 。行，现在还没有变化，列有 12 列。
首先你肯定会注意到了它们的 am前缀(am-prefix)。这是 AM 核心的一部分，它确保了属性模块不会和现有属性冲突。你也可以用任意你喜欢的 ‐ 我试过用 ui- ，css- 还有其它一些，不过这个例子里面我们约定用 am-。如果 HTML 校验对你的或者你项目来说很重要，那你就选个 data-，意思也是一样的。 第二个你会注意到应该就是那些值了，什么 "1"，"4" 还是 "12" 的，看起来非常糟糕 的类名 ‐ 它们太普通所以有太高的冲突几率了。不过因为我们已经定义了我们的命名空间，它只在我们规定的地方起作用，所以我们可以随便用那些我么你觉得最简明最有意义的字符。 灵活的属性到目前为止，差别相当细微。不过因为每个模块都有它自己的命名空间，让我们拿我们的值做个不一样的尝试:
现在我们可以用命名来让我们的作用域看起来更有意义了 ‐ 一个宽是 1/3 标记让我们立刻能想起我们需要有 4 列，因为我们用的是一个 12-列 的网格。我们还为所有的列定义了一个默认样式 ‐ 也就是属性 column ，没有值的列将会被视为全宽的列。此外，我们还可以把一些重复的逻辑 (事实上列是左对齐的)移到了这个属性规则里面。 格式化所有的属性和值这是这种方法的核心优点之一。存在一个基础属性，比如 am-Button，可以并且应该定义样式。这个属性的每个扩展值则应该继承或者重写这个基础样式。 在上面的网格例子中，我们正是这样做的：标签 am-Column="1/3" 匹配到了两个属性[am-Column] 和 [am-Column~="1/3"]，因此结果就是基础样式 + 改变。它给我们提供了一种方式来实现 所有的列都是columns 而不需要用重复的类或者用 SASS 的 @extend方法。 BEM 的零类(zero-class)模式回到我们的 BEM 中的单类模式 vs 多类模式上来，AM 给了我们一个零类模式选项。比如说上面的按钮的例子，标记看起来是这样的:
通过创建一个新的属性模块 am-Button，我们可以分离出适用于所有按钮的样式，比如那些大按钮，还有那些圆角按钮。我们不仅可以自由的组合这些变化(比如 am-Button='large rounded')，我们还可以针对这些属性本身做任何的上下文覆盖:
现在不管你选什么样式的按钮，或者你选多少种样式的按钮都不是问题了，关键是，所有的按钮都会适用选择器[am-Button]，这样我们就知道我们的覆盖是有效的了。 AMCSS 工程我, 本・施瓦兹和本・史密西特已经开始为 AM 的规范而努力了。如果你想了解这项技术更多的细节，比如块(blocks),元素(elements),断点(breakpoints) & 更多的话，去看看吧，如果你有问题要问，请戳这里提出问题。 同时我们也发布了文档站点 amcss.github.io ，那有大量的例子。如果你有兴趣贡献回馈，例子，特例或者希望我们给你的 AM 库加链接的话，请移步到我们的 GitHub。 |
