可扩展 CSS 的演化

发表于 1年以前 | 总阅读数：477 次

自从 Web 诞生以来，我们思考和编写 CSS 的方式发生了巨大变化。从基于表格的布局到响应式设计，我们已经走过了很长一段路，随着现代 CSS 功能越来越强大，如今进入了自适应布局的新阶段。但是一直以来，管理和组织 CSS 都是一项颇有挑战的工作，而且很难达成共识。

在这篇文章中，我们将对 CSS 进行更深入的理解，研究使其难以扩展的底层问题。我们将回顾各种 CSS 最佳实践的演变过程，它们伴随着时间而发展和变化。最后，我们将探讨如何在大型项目上实现可扩展的 CSS，以及 Tailwind 等一系列工具是如何解决这些问题的。

CSS 诞生之前

起初，Web 只有 HTML。我们用大写字母书写页面，直接使用标签上的属性设置页面样式：

  <BODY>
    <P SIZE="8" COLOR="RED">LOUD NOISES</P>
  </BODY>

对于那些想要好看页面的人来说，这是一个黑暗时代。除了有限的可用样式之外，还要不断重复地书写样式。这一时期，非常有代表性的例子是Space Jam 网站。

放到现在，可能有些人会想 “这看起来像是传递组件中的 props”，正如我们稍后将看到的那样，世间万物千回百转，经过不断的演变，最终又归于原点。

样式表的关注点分离

CSS 的出现让我们不必重复的书写样式，让我们能够以声明的方式来设置页面样式，只需很少的代码即可影响大量元素：

p {
  color: red;
}

现在，我们可以将页面的内容结构及其视觉上的外观布局独立开来。将布局问题从基于表格的 HTML 转移到 CSS 中来。最初 CSS 是比较小的，它深受物理桌面启发，比如用术语 “float” 来支持文本格式。

随着时间的推移，我们开始在一个名为CSS Zen Garden的网站上收集 CSS 示例。CSS Zen Garden 逐渐成为展示如何创造性地使用 CSS 的中心。大家通过有趣和独特的方式，对同一份 HTML 重新设计样式。这在传播内容与样式分离、可重置样式的 HTML 以及将主题化的 “皮肤” 应用于核心框架想法等方面非常有影响力。

探寻最佳实践

当我们开始构建更复杂的网站和应用程序，也对 CSS 提出了新的要求。任何新技术在最佳实践出现之前，通常都需要经历不断的探索和尝试。

我们看到 Less 和 Sass 等工具涌现出来，它们扩展了原生 CSS 能力。为我们提供了变量和计算函数之类的东西，大大改善了开发人员的体验。

随着在这些样式中花费的时间不断增加，我们也在不断探寻组织这些规则和选择器的方法。于是出现了许多提高 CSS 扩展性的模式，这些模式试图在可维护性、性能和可读性之间取得平衡，被称为 “CSS 架构”。

在深入研究这些架构之前，让我们先了解为什么在大型项目上管理 CSS 会变得很复杂。

为什么 CSS 在大型项目中难以管理

“大型项目” 通常会涉及多个方面，比如人、工具、过程和性能。

为了能够有效地扩展，需要谨慎地应对复杂度的增长。因此，随着系统的迭代，需要保证它依然是可理解的、可改变的和可执行的。添加新代码的成本尽可能低，人们才会有信心更改和删除旧代码。

级联（CSS 中的 C）起源于 Web 的早期。浏览器可以将默认样式应用于这些新的电子文档。然后，文档作者可以提供自己的样式，这些样式可以被某个用户覆盖。

级联规则是理解 CSS 的核心。支持对相同属性设置使得 CSS 很强大，但是也使得在大型项目中很难扩展这些属性，特别是 CSS 的全局命名空间、级联规则和选择器权重。

全局命名

如果谨慎使用 CSS 全局命名空间，它会很强大。但在大型项目中，这恰恰是一种诅咒。当所有一切都是全局时，任何改动都可能影响到其它地方。无论是现在还是未来，只要发生变化就存在这样的风险。

这样一来很快就会造成问题。这也是在其它语言中，不会将所有内容放在全局命名空间的原因。随着代码的增加，代码会变得愈发不可预测，维护起来也越来越困难。

值得注意的是，CSS 即将出现的一个特性 -- CSS 级联层（Cascade Layers），可以帮助我们解决这个问题。

难于命名

当项目的 CSS 在快速迭代时，创建一系列语义化类名通常会很烦琐，也不会带来什么收益。找到一个有用的名字是很难的，因为我们正试图将一堆信息压缩成一个精确的标签。特别是当这一切都是全局的，正确地处理这一点变得更加重要。

过早命名是过早抽象的一种形式。因为通常我们命名的东西仍未完全成形，而且还不能重复使用。设计的变更在前端很常见，有些标签很快会过时，需要对样式和 HTML 进行重构。

难于重构

现代软件的设计和开发都是快速迭代的，通常我们只有在几次迭代之后才会有清晰的认知。这要求我们定期重新评估对正在解决的问题的理解程度。也意味着，随着我们认知的迭代而重构代码。

重构可能很有挑战性，但它是一种久经考验的方法，可以根据实际需求而不是理论来获得好的抽象。但是，重构 CSS 相当困难。由于许多 CSS 错误都是 “无声的”，如果没有可靠的视觉回归测试，很容易产生无法预料的错误和副作用。这导致了几个常见的场景。

** 仅附加 CSS ** 最初，管理项目的样式是很容易的。但是，经过几次迭代后，通常新代码会添加在文件的末尾。我们都知道，安全地更改或删除样式规则是很难的，而更简单的做法是，在文件末尾添加代码来覆盖之前的样式内容。这就会遇到权重问题。我们都有过重写某个样式的经历，使用黑魔法 !important 能够轻松实现，但这也不可避免地加重了维护负担。
** 死代码 ** 在实践中，我们经常要重复使用相同的 CSS 属性。在这种场景下，在重构全局命名空间中的 CSS 会有很大风险，复制一份样式规则相对比较安全。这样复制样式会引起大量未使用的 CSS，很难知道是否有东西依赖它。最终导致未使用的 CSS 散布在各个文件。

难于调试

调试的作用是在我们大脑中模拟计算机所做的事情。调试复杂的 CSS 会很困难，因为我们在思考源代码顺序的同时，需要在心里计算级联和最终规则。

尤其是 CSS 在定位、对齐、堆叠上下文、边距和高度方面的众多细微差别。如果没有系统的方法，常见的调试 CSS 的流程是，调整一些值并且查看发生哪些变化。刷新页面之后，要么没有任何变化，要么一切都被破坏了。

当处理无法控制的代码或特定的浏览器错误时，这尤其具有挑战性。

利用 CSS 架构控制复杂性

CSS 在简单的同时，也很容易让事情变得混乱。最终，我们开始寻求软件工程原理来帮助我们管理 CSS。这些架构更像是一个蓝图，用于组织 CSS 文件及其规则和选择器。让我们快速了解一些有影响力的、流行的 CSS 架构及其主要思想。

OOCSS：面向对象的 CSS

OOCSS 对我们在实践中编写的不同类型的 CSS 进行区分。比如，布局的 CSS，以及做主题或 “皮肤” HTML 的 CSS（如颜色、字体等）。在 OOCSS 中的 “对象” 是一种可以抽象和复用的视觉模式。其思想是识别那些常见的视觉模式，并将重复的代码块提取到可重用类中。最广泛使用的 CSS 框架之一 Bootstrap，就使用了 OOCSS 思想的。

SMACSS：可扩展和模块化 CSS

在实践中，大型单文件 CSS 文件很快变得不可管理且难以调试。SMCASS 是对不同类型的 CSS 进行分类，与 OOCSS 等方法兼容。它主要的思想是将所有这些类名，组织到单独的分类中，并为我们的 CSS 文件提供一些急需的结构。另外，还提供了一些类名的命名约定。

BEM：块、元素、修改器

BEM 是一个模型，将样式分解为组件、子元素及其各种离散状态。它最初源自于 Yandex，提供了一个系统的命名约定，保持所有选择器都是扁平的（没有后代选择器），从而避免了优先级问题，其中每个被设置样式的元素都有自己的类名。

BEM 与流行的 CSS 预处理器（比如，带有嵌套规则的 Sass）结合得很好，这些规则可以编译为扁平的 CSS 选择器：

.nav {
  // block styles
    &__link {
    // element styles that depend on the parent block
        &--active {
          // modifer styles
        }
    }
}

ITCSS：倒三角形

ITCSS 的一个主要思想是对样式表分层，来帮助我们控制级联。ITCSS 是一个类似于 CSS 的 “元框架”，与其他系统兼容。它提供了基于优先级的层级结构，来控制那些不可预测带来的混乱。“倒三角形” 与倒金字塔形状类似。这是在管理大型项目 CSS 文件中的一种有影响力的方法。

Cube CSS

Cube CSS 使用全局命名空间和级联，而不是试图绕过它。Cube CSS 提供了一组定义良好的类别，用于对 CSS 进行分类。这些组成了 Cube 的首字母缩写：Composition、Utility、Block、Exception。这是一种松散的方法，可以看作是组织 CSS 的心理模型。与 ITCSS 类似，它是一个有影响力的 “元 CSS 框架”，兼容各种方法。

重新思考关注点的分离

随着 SPA 和组件驱动开发的兴起，我们开始看到 CSS 的新方法。当下，管理 CSS 变得更加困难，因为组件是异步加载的，无法保证加载顺序。一个常见的问题是，当执行从页面 A 到页面 B 的 SPA 转换时，页面上的某些元素看起来不同，但如果直接加载到页面B，则看起来很好。

我们开始寻找更具体的解决方案来管理 CSS，与这种新的以组件为中心的构建前端的方法相结合。这些工具经常打破我们迄今为止一直在建立和思考的许多既定最佳实践。下面来了解一下。

内联样式

在基于组件的框架中，比如 React，我们将 JavaScript 对象传递给 style 属性，最终将其转换为内联样式。这会让很多人的内心泛起涟漪，我们仿佛是抛弃了已有的最佳实践，回到了最初没有样式表的起点。

在组件的上下文中，内联样式不会引起大量的样式重复的问题，因为它被封装在组件中。事实上，这些样式只影响它们所在的元素，因此在组件中添加和修改 CSS 是安全的。

内联样式的主要问题是无法使用更强大的 CSS 功能，如伪选择器和媒体查询。除此之外，也很难使用设计变量的复用、缓存、静态分析和预处理等。

CSS in JS

在 React 的早期，Veujx 就 Facebook 使用 CSS 方法进行了演讲。从表面上看，与内联样式很像，但可以使用 CSS 强大功能。这次演讲导致采用 Javascript 驱动的 CSS 方法的开源库激增。

第一波 CSS in JS 库因为 Styled Components、Emotion 等库而流行。它们解决了原生 CSS 在使用组件的大型项目中遇到的很多问题，使得处理 JavaScript 中的动态值变得非常容易。但是带来的问题是用户体验受损。CSS in JS 存在服务器端渲染效率低下、缓存问题和客户端运行时成本问题。这让应用的启动时间更加缓慢，一旦 JavaScript 进行 hydrate 就需要多次重新渲染。在大型应用中要额外的工作来处理这些问题。

第二波 CSS in JS 库旨在在不增加运行时成本的情况下为开发人员提供最佳体验。Linaria、Compiled、Vanilla extract 等工具可以在编译中从组件中提取样式表。这将在用户浏览器运行时发生的大部分事情转移到了编译时。CSS 通常被编译成 Atomic CSS 以避免 CSS 文件臃肿，并且与动态运行时样式表相比更容易缓存。

CSS Modules

CSS Modules 可以让我们在编写常规 CSS（或 Sass）和可扩展性之间取得平衡。CSS Modules 允许我们使用 CSS 的全部功能，而不必担心样式在组件中溢出，同时将样式内容保存在组件目录中。

特别是在第一波 CSS in JS 库的浪潮中，将 CSS 绑定到特定的库对一些人来说很难接受，CSS Modules 就是一个很好的选择。然而，有些人可能认为这是 CSS in JS 的一种形式，因为它依赖于像 Webpack 这样的打包工具来生成并确保选择器的作用域。

无论如何，CSS Modules 是常规 CSS 世界和完全以组件为中心的方法（如 CSS in JS）之间的一个很好的折中方法。不过，仍然需要进行命名并，可以与 BEM 等约定兼容。

对 CSS 最佳实践的挑战

与此同时，在基于组件的 SPA 世界之外，最初受 CSS Zen Garden 影响的最佳实践也面临着挑战。Atomic CSS 诞生于在大型项目上管理 CSS 的黎明前的黑暗。它最初的动机就是在编写样式时，无需对已有的 CSS 进行编辑或附加规则。避免随之而来的所有问题。

与 OOCSS、BEM 和 SMACSS 等其他 CSS 架构相比，Atomic CSS 完全违反直觉，它比 “块” 和 “对象” 低一级，专注于单一用途的原子。直接违背了既有的最佳实践，甚至违反了 HTML 规范中推荐的 CSS 命名方式。

对于那些修改已有 CSS 存在较大风险的项目团队，它已成为一种流行的提高生产力的方法。那些使用 Atomic CSS 的流行 CSS 库有 ACSS、Tachyons、WindiCSS 等，而根据一份 CSS 调查显示，Tailwind CSS 框架是这种 CSS 架构最流行的实现。

Tailwind 的崛起

自 2017 年发布以来，Tailwind 迅速受到开发者欢迎。Tailwind 的特点是降低了 CSS 的使用难度，能够极大提高生产力，即便你不是专家，同时也让 CSS 更易于维护。大家使用之后都说，“用了，你就回不去了”。

Tailwind 的基本原则

为了了解它为什么如此受欢迎，下面来研究一下 Tailwind 方法背后的基本原则。尽管看似抛弃了既定的最佳实践，但下面将介绍一系列其在实践中行之有效的实用原则。尽管表面上抛弃了已有的最佳实践，但我们会看到，其背后是一系列在实践实用的原则。

推迟命名

不必不断地为事物命名是让 Tailwind 感觉高效的原因之一。这背后是由一系列自下而上的单一用途的原子样式支撑的。从可维护性的角度来看，这是避免草率抽象的好方法。

从不命名任何东西会影响代码的可读性。通常会导致一大堆没有明确界限的原子类（或组件）。这个观点本身没有错，但是在实践中，我们亟待解决那些要命的痛点问题。在经常更改或与许多人一起更改的代码库中，这通常是一个正确的取舍。

在基于组件的开发模式中，我们已经为正在使用的组件创建了一个语义名称，而这个名称也包含了组件内部使用的样式。从某种程度上讲，我们实现了更高层次上的抽象。因此，我们不是永远不抽象，而是不要过早地抽象。

适时抽象

在开发迭代过程中，能够轻松删除和更改代码大大超过了复制代码的成本。在编写 CSS 时，一个常见的痛点是，当我们过度处理重复代码或优化导致后续很难改变时，通常会感觉像是浪费。与处理过度抽象的代码并使其适用于新的场景相比，在一个通用的抽象中处理重复代码要简单的多。

Tailwind 提供了两种在适当的时候进行抽象的技术，一种是创建一个共享的 CSS 类来表示一个块（类似于 OOCSS）。或者在使用基于组件的框架时，更鼓励的做法是将重复的类提取到可重用（React、Vue、Solid、Svelte 等）组件中并共享它。

有信心重构

因为类是根据它们所在的 HTML 进行本地化的，所以可以放心地重构这些类，而不必担心其它元素或组件受到影响。这适用于作为文档的 Web 心智模型和以组件为中心的模型。这导致了一种感觉，即 Tailwind 可以根据正在构建的站点或应用的类型进行扩展。

避免死代码

预编译为 Atomic CSS 的 Tailwind 和 CSS in JS 解决了充满重复规则的臃肿 CSS 文件的问题。使用 Atomic CSS，CSS 的增长与使用的样式数量相关，而不是开发人员提供的功能数量。例如，到处重用某些属性（如 flex）是很常见的。与其在不同类名下的样式表中复制这些内容，不如只写一次。对于每个属性 / 值的组合都是如此。