访客 - 原文地址：WhatisModularCSS?
- 原文作者：ScottVandehey
- 译文出自：掘金翻译计划
- 本文永久链接：github.com/xitu/gold-m…
- 译者：ssshooter
- 校对者：HopskenPark-ma
模块化CSS是一组编写代码的原则，基于这个原则编写的代码具有高性能和可维护性。它起源于雅虎和Yandex的开发人员，目的是迎接维护大型代码库带来的挑战。有些规则在提出之初稍有争议，但后来被认为是最佳实践。
目录：
- 大规模CSS的处理难点
- 什么是模块化
- 模块化框架
- OOCSS
- BEM
- SMACSS
- 共享模块化原则
- FAQ
- 总结，模块化CSS太美妙啦
（偷偷告诉你：如果你对这篇文章的篇幅感到不知所措，观看视频可能更适合你，这篇文章来源于此演讲。）
大规模CSS的处理难点模块化CSS使用的主要场景是棘手的大规模CSS。正如NicholasGallagher所说的：
来源：NicholasGallagher，图：dotCSS
这句话直指大规模CSS问题的核心。写代码并不难，难的是在不让你的代码随着时间的推移成为拖累你的“技术债”。
难以理解以下是CSSGuidelines中的一个示例，这个示例展示了一个问题：除了写这段代码的人，没有人知道这段代码是干什么的。
<divclass="boxprofilepro-user"><imgclass="avatarimage"/><pclass="bio">...</p></div>box和profile有什么关系？profile和avatar有什么关系？或者他们之间真的有关系吗？你应该在bio旁边添加pro-user吗？image和profile写在同一部分CSS吗？可以在其他地方使用avatar吗？
光看代码无法回答这些问题，你必须在CSS代码中推理他们的作用。
难以复用复用代码会非常棘手。假设你要在另一个页面上复用某个页面上的样式，但你想这么做的时候，会发现那个样式是专为第一个页面而写的。代码的作者认为它只用在某个特定元素中，或者它是从页面继承某些类，在其他环境中根本不起作用。你不想修改原来的内容，然后直接复制了代码。
现在你有两个问题：一份原始代码，一份重复代码，你的维护负担直接增加了一倍。
难以维护大规模的CSS也难以维护。你改变了一个标签，样式就会像纸牌屋一样崩溃。你想更新一个页面上的样式，却破坏了另一个页面的样式。你试图覆盖其他页面，但又深陷于优先度问题。
它让我想起了我最喜欢的CSS笑话之一：
什么是模块化那么我们如何解决这些问题呢？答案在于模块化这个概念，但这是什么呢？我们先看看HarryRoberts对关注点分离的见解：
来源：HarryRoberts，图：CSSwizardry.com
这是一个常见编程习惯，但是许多CSS开发者不太熟悉。这个思想是确保你所写的东西不会比你想要做的更多。
举个例子，说明我在学习模块化CSS之前的工作方式。设计师给我这样的草图：
图：Yandex
我会觉得：“好吧，这是一个书店页面，侧边栏中有一些小部件，右侧列出了大概是书籍封面的清单，一个精选书评，下面还有其他的评论。”
我当时认为一个页面是一个完整的单元，页面里的较小部分从属于页面。这是一种自上而下的思考方法，这导致大量只服务于单个页面的一次性代码，不利于编写可复用代码。
图：Yandex
模块化CSS需要你换一个角度看问题，不从页面级别考虑，而是关注组成页面的小块。这不是一个页面而是一个组件的集合。
你会发现页面里包含的是logo，搜索栏，导航，照片列表，辅助导航，标签框，视频播放器等。这些是可以网站的任何位置都可以独立使用的内容。它们只是碰巧在这个特定页面以这种方式组合。
模块化CSS是自下而上的思维，需要从构建整个站点的可复用构建模块开始。
图：BEMMethod
这会让你想起乐高？应该的！几乎所有撰写有关模块化CSS的人都使用乐高进行类比。使用标准化，易于理解，并且不依赖上下文的块来构建UI的是一个很好的思路。
这样的“块”最著名的例子之一是由NicoleSullivan定义的“媒体对象”，她认为这种对象是你将在任何网站上找到的最小的组件之一。
它将固定宽度的图像组合到灵活宽度的容器的一侧，现在到处都可以看到这个模式。她撰写了一篇名为TheMediaObjectSavesHundredsofLinesofCode的案例研究，谈到将此模式应用于大型网站，最大的例子之一便是Facebook：
图：NicoleSullivan
这里高亮显示了Facebook流中的所有媒体对象。左上角个人信息，右侧导航元素，订阅的每个帖子，甚至是广告都是媒体对象。有时它们彼此嵌套。虽然使用目的不同，但它们都共享相同的基础模式：固定宽度的图像，弹性宽度的文本。
她的观点是，以Facebook的规模运营时，媒体对象就不止几十个，这样的页面上有数百上千个。因此，可以想象如果为复用样式作优化，可以节省大量代码，这可以带来真正的高性能和低成本。
模块化框架那么，既然我们已经明确了模块化的概念，那么让我们看看这些年来推崇这一概念的三大框架：
OOCSS面向对象的CSS（Object-OrientedCSS）/OOCSS是模块化CSS的起源，由NicoleSullivan于2009年提出，这基于她在雅虎的工作。这个框架的核心思想是——对象是可重用的模式（pattern），其视觉外观不由上下文决定。
- 有人质疑雅虎的能力，雅虎的前端团队当时研发的YUIlibrary是非常前沿的技术。在2009年，雅虎不是一家没有前途的科技公司。
来源：NicoleSullivan，图：JohnMorrison
正如她在2009年所定义的那样，这就是模块化CSS的起源。除此之外，OOCSS可归结为几个核心原则：
上下文无关首先，无论你把它放在哪里，一个对象都应该看起来无差别，不应根据对象的上下文设置对象的样式。
例如，不是将侧边栏中的所有按钮都设置为橙色，将主区域中的所有按钮设置为蓝色，而是应该创建一个蓝色的按钮类，以及一个橙色的modifier。这样做橙色按钮可以在任何地方使用，它们没有被绑定在侧边栏上，它们只是你的按钮样式之一。
皮肤（主题）她谈到的另一个概念，是如何从正在应用的皮肤中抽象出对象的结构。
我们可以回到媒体对象的例子。它的样式与标签结构无关。有一个容器，一个固定宽度的图像和内容。你可以应用不同的样式，但是无论样式如何改变，标签结构都是一样的。
她建议的其他方法是为常见的视觉模式创建可复用的类。她给出了一个例子，在2009年的亚马逊网站几乎所有的东西都有阴影，但因为它们由不同设计师创作，所以相似却不相同。通过标准化这些元素阴影，可以优化代码并使网站更高效。
使用Class当时她提出了一个非常具有争议性的规则，但后来被广为接受：使用class来命名对象及其子元素，这样可以在不影响样式的情况下修改HTML标签。
她不希望CSS由HTML标签来确定，这样的话如果将标题从“h1”更改为“h4”，则不必更新CSS。无论选择哪个标签，该标题应该有一个固有的class。例如，你的导航应该类似于.site-nav而不是#headerul。
既然建议“总是使用class”，那么自然禁止使用ID选择器。这与当时使用ID作为命名空间的常见实践相违背，直接引用嵌套在其中的元素。
ID会扰乱CSS优先度，这是其次，对象必须是可复用的。根据定义，ID是唯一的。因此，如果在对象上设置ID，则无法在同一页面上重复使用它，缺少了模块化对象的要点。
BEM接下来介绍下一个弘扬模块化CSS精神的框架。BEM，三个字母分别代表Block、Element、Modifier，BEM也是在2009年提出，起源于Yandex（可以说是俄语版的Google），除搜索业务外还运营网络邮件程序，因此在编程上他们也需要解决与雅虎相同规模的难题。
他们提出了一套非常类似的代码原则。他们的核心概念是——块（block）（Nicole称之为“物体（object）”）由子元素（element）构成，并且可以修改（modified）（或“主题化”）。
以下是其中一位负责BEM的开发者VaryaStepanova对BEM的描述：
来源：VaryaStepanova，图：ScotlandJS
BEM由3部分组成：
块（Block）块是网页逻辑和功能的独立组件。BEM的发起人对其提出了更详尽的定义：
首先，块是可嵌套的。它们应该能被包含在另一个块中，而不会破坏任何样式。例如，可能在侧栏中有一个标签界面小部件的块，该块可能包含按钮，这些按钮也是一种单独的块。按钮的样式和选项卡式元素的样式不会相互影响，一个嵌套在另一个中，仅此而已。
其次，块是可重复的。界面应该能够包含同一块的多个实例。就像Nicole所说的媒体对象一样，复用块可以节省大量代码。
元素（Element）元素是块的组成部分，它不能在块之外使用。一个不错的例子：一个导航菜单，它包含的项目在菜单的上下文之外没有意义。你不会为菜单项定义块，菜单本身应定义为块，而菜单项是其子元素。
修饰符（Modifier）修饰符定义块的外观和行为。例如，菜单块的外观的垂直或水平，取决于所使用的修饰符。
命名约定BEM所做的另一件事是定义了非常严格的命名约定：
.block-name__element--modifier
这看起来有点复杂，我来分解一下：
- 名称以小写字母书写
- 名称中的单词用连字符（
-）分隔 - 元素由双下划线（
__）分隔 - 修饰符由双连字符（
--）分隔
这么说也有点抽象，举一个例子：
现在我们有一个标准的乐高minifig。他是一个蓝色的宇航员。我们将使用.minifig类来区分他。
可以看到.minifig块由较小的元素组成，例如.minifig__head和.minifig__legs。现在我们添加一个修饰符：
通过添加.minifig--red修饰符，我们创建了标准蓝色宇航员的红色版本。
或者，我们可以使用.minifig--yellow-new修饰符将我们的宇航员改为新式黄制服版。
你可以使用同样的方式进行更夸张的修改。通过使用.minifig--batman修饰符，我们只用一个类就改变了minifig的每个部分的外观。
这是实践中的BEM语法例子：
<buttonclass="btnbtn--bigbtn--orange"><spanclass="btn__price">$9.99</span><spanclass="btn__text">Subscribe</span></button>即使不看样式代码，你也可以一眼就看出这段代码会创建一个既大又橙的价格按钮。无论你是否喜欢带有连字符和下划线的这种风格，拥有严格的命名约定是模块化CSS向前迈出的一大步，这让代码带有自文档的效果！
不嵌套CSS就像OOCSS建议使用class而不使用ID一样，BEM也为代码风格作了一些限制。最值得注意的是，他们认为不应该嵌套CSS选择器。嵌套选择器扰乱了优先度，使得重用代码变得更加困难。例如，只需使用.btn__price而不是.btn.btn__price。
注意：这里的嵌套指实践中在Sass或Less嵌套选择器的做法，但即使你没有使用预处理器也适用，因为这关乎选择器优先度问题。
这个原则不出问题是因为严格的命名约定。我们曾经使用嵌套选择器将它们隔离在命名空间的上下文中。而BEM的命名约定本身就提供了命名空间，因此我们不再需要嵌套。即使CSS的根级别的所有内容都是单个类，但这些名称的具体程度足以避免冲突。
一般来说，选择器可以在没有嵌套的情况下生效，就不要嵌套它。BEM允许此规则的唯一例外是基于块状态或其修饰符的样式元素。例如，可以使用.btn__text然后用.btn--orange.btn__text来覆盖应用了修饰符按钮的文本颜色。
我们最后要讨论的框架是SMACSS，含义是CSS的可扩展性和模块化架构（Scalable&ModularArchitecture）。JonathanSnook于2011年提出了SMACSS，当时他在雅虎工作，为YahooMail编写CSS。
来源：JonathanSnook，图：ElidaArrizza
他在OOCSS和BEM的基础上添加的关键概念是，不同类别的组件需要以不同的方式处理。
类别（Categories）以下是他为CSS系统可能包含的规则定义的类别：
- 基础（Base）规则是HTML元素的默认样式，如链接，段落和标题。
- 布局（Layout）规则将页面分成几个部分，并将一个或多个模块组合在一起。它们只定义布局，而不管颜色或排版。
- 模块（Module）（又名“对象”或“块”）是可重用的，设计中的一个模块。例如，按钮，媒体对象，产品列表等。
- 状态（State）规则描述了模块或布局在特定状态下的外观。通常使用JavaScript应用或删除。例如，隐藏，扩展，激活等。
- 主题（Theme）规则描述了模块或布局在主题应用时的外观，例如，在YahooMail中，可以使用用户主题，这会影响页面上的每个模块。（这非常适用于像雅虎这样的应用程序，但大多数网站都不会使用此类别。）
下一个原则是使用前缀来区分类别，他喜欢BEM明确的命名约定，但他还希望能够一目了然地看出模块的类型。
l-用作布局规则的前缀：l-inlinem-用作模块规则的前缀：m-calloutis-用作状态规则的前缀：is-collapsed
（基础规则没有前缀，因为它们直接应用于HTML元素而不使用类。）
共享模块化原则这些框架的相同之处远胜于其不同之处。我看到从OOCSS到BEM再到SMACSS的明确发展。它们的发展代表了我们行业在性能和大规模CSS领域不断增长的经验。
你不必选择其中一个框架，相反，我们可以尝试定义模块化CSS的通用规则。让我们看看这些框架共用和保留的最佳部分。
模块化元素模块化系统由以下元素组成：
- 模块（Module）：（又名对象，块或组件）一种可复用且自成一体的模式。如媒体对象，导航和页眉。
- 子元素（ChildElement）：一个不能独立存在的小块，属于模块的一部分。如媒体对象中的图像，导航选项卡和页眉logo。
- 模块修改器（ModuleModifier）：（又名皮肤或主题）改变模块的视觉外观。如左/右对齐的媒体对象，垂直/水平导航。
模块化系统中的样式可以分为以下几类：
- 基础（Base）规则是HTML元素的默认样式，如：
a、li和h1 - 布局（Layout）规则控制模块的布局方式，但不控制视觉外观，如：
.l-centered、.l-grid和.l-fixed-top - 模块（Modules）是可复用的，独立的UI组件视觉样式，如：
.m-profile、.m-card和.m-modal - 状态（State）规则由JavaScript添加，如：
.is-hidden、.is-collapsed和.is-active - 助手（Helper）（又名功能）规则适用范围小，独立于模块，如：
.h-uppercase、.h-nowrap和.h-muted
在模块化系统中编写样式时，请遵循以下规则：
- 不要使用ID
- CSS嵌套不要超过一层
- 为子元素添加类名
- 遵循命名约定
- 为类名添加前缀
模块化CSS最常见的反对意见就是，它会在HTML中产生许多类。我认为这是因为长期以来CSS的最佳实践都认为应该避免大量class使用。早在2011年，NicoleSullivan就写了一篇很棒的博文Our(CSS)BestPracticesareKillingUs，明确驳斥了这个想法。
我看到一些开发人员提倡使用预处理器的extend函数将多个样式连接成一个类名。我建议不要这样做，因为它会使你的代码不那么灵活。他们不能让其他开发者以新的方式组合你的乐高积木，而是固定了你定义的几种组合。
不要因为类名太长而害怕，他们是自文档的！当我看到BEM风格的类名（或任何其他模块化命名约定）时，我会觉得很愉悦，因为只要看一眼就能知道这些类的含义。你可以在HTML中清晰理解它们。
孙元素的命名如何约定？长话短说：没这回事。
模块化CSS初学者可以快速掌握子元素的概念：minifig__arm是minifig的一部分。然而，有时候他们处理CSS中的DOM结构时，会疑问如何作深层嵌套，比如minifig__arm__hand。
没有必要这样做。请记住，这个思路是要将样式与标记分离。无论hand是minifig的直接子元素还是嵌套了多少层，都无关紧要。CSS关心的只有hand是minifig的孩子。
.minifig{}.minifig__arm{}.minifig__arm__hand{}/*don'tdothis*/.minifig__hand{}/*dothisinstead*/模块冲突怎么办？模块化CSS初学者比较关注的另一件事是模块之间的冲突。例如，如果我将l-card模块和m-author-profile模块同时应用于同一个元素，是否会导致问题？
答案是：理想情况下，模块不应该重叠太多。在这个例子中，l-card模块关注布局，而m-author-profile模块关注样式，你可能会看到l-card设置宽度和边距，而m-author-profile设置背景颜色和字体。
测试模块是否冲突的一种方法是以随机顺序加载它们。你可以将项目构建配置中设定为在构建时随机交换样式位置。如果看到bug，就证明你的CSS需要以特定顺序加载。
如果你发现需要将两个模块应用于同一个元素并且它们存在冲突，请考虑它们是否真的是两个独立的模块。也许它们可以用一个修饰符组合成一个模块？
该规则的最后一个例外是“helper”或“utility”类可能会发生冲突，在这些情况下，你可以安全地考虑使用!important。我知道，你曾被告知!important不是什么好东西，永远不应该被使用，但我们的做法有细微的差别：主动使用它来确保helper类总是优先还是不错的。（HarryRobertshasmoretosayonthistopicintheCSSGuidelines。）
我们来简要回顾一下，还记得这段代码吗？
<divclass="boxprofilepro-user"><imgclass="avatarimage"/><pclass="bio">...</p></div>box和profile有什么关系？profile和avatar有什么关系？或者他们之间有关系吗？你应该在bio旁边添加pro-user吗？image和profile写在同一部分CSS吗？可以在其他地方使用avatar吗？
现在我们知道如何解决这些问题了。通过编写模块化CSS并使用适当的命名约定，我们可以编写自文档的代码：
<divclass="l-boxm-profilem-profile--is-pro-user"><imgclass="m-avatarm-profile__image"/><pclass="m-profile__bio">...</p></div>我们可以看到哪些类彼此相关，哪些类彼此不相关，以及如何相关。我们知道在这个组件的范围之外我们不能使用哪些类，当然，我们还知道哪些类可以在其他地方复用。
模块化CSS简化了代码并推进了重构，产出自文档的代码，这样的代码不影响外部作用域且可复用。
或者换句话说，模块化CSS是可预测的，可维护的并且是高性能的。
现在我们可以重温那个老笑话，结局发生了变化：