将CSS层叠层集成到现有项目中

本文旨在分享将CSS Cascade Layers集成到现有遗留代码库的完整实践过程。实际上，这是关于在不破坏任何现有功能的前提下，重构现有CSS以使用层叠层的方法。

虽然可以通过Stephanie Eckles的文章《Getting Started With CSS Cascade Layers》获得很好的概述，但让我们谈谈将层叠层集成到真实世界代码中的经验：好的、坏的和混乱的部分。

理解项目

在开始使用@layer之前，我们需要充分理解正在处理的内容。我克隆了GitHub仓库，由于我们的重点是使用CSS Cascade Layers，我将只关注由三个文件组成的主页：index.html、index.css和index.js。

index.css文件超过450行代码，浏览时我立即发现了一些危险信号：

存在大量指向相同HTML元素的重复选择器代码
有不少#id选择器（有些人认为不应在CSS中使用）
#botLogo被定义了两次，且相隔70多行
!important关键字在整个代码中被随意使用

但网站仍然正常工作。这里没有"技术性"错误，这也是CSS既强大又复杂的原因——错误是静默的！

规划层级结构

有些人可能会想：“我们不能简单地将所有样式移入单个层级，比如@layer legacy，然后就完事了吗？”

你可以这样做……但我不认为你应该这样做。

考虑到：如果在legacy层之后添加更多层，它们应该覆盖legacy层中包含的样式，因为层的特异性是按优先级组织的，后面声明的层具有更高的优先级。

1
2
3
4
5


/* new层更具体 */
@layer legacy, new;

/* legacy层更具体 */
@layer new, legacy;

但我们必须记住，网站现有样式大量使用了!important关键字。当这种情况发生时，层叠层的顺序会被反转。因此，即使层是这样定义的：

1

@layer legacy, new;

任何带有!important声明的样式都会改变优先级顺序。在这种情况下，优先级顺序变为：

legacy层中的!important样式（最强大）
new层中的!important样式
new层中的普通样式
legacy层中的普通样式（最不强大）

集成层叠层

我们需要在文件顶部定义层顺序：

1

@layer reset, base, layout, components, utilities;

这使我们可以轻松判断哪个层优先于哪个层（从左到右优先级递增），现在我们可以根据层责任而不是选择器权重来思考。

重置层

通用选择器（*）样式包含经典的重置样式，非常适合放在@layer reset中：

1
2
3
4
5
6
7


@layer reset {
  * {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
  }
}

基础层

body选择器接下来。我将其放入@layer base，因为它包含项目的核心样式：

1
2
3
4
5
6
7


@layer base {
  body {
    background-image: url("bg.svg");
    font-family: "Poppins", sans-serif;
    /* ... 其他样式 */
  }
}

将ID转换为类

我坚信尽可能使用类选择器而不是ID选择器。这默认保持低特异性，防止特异性冲突，使代码更易维护。

我将id="loader"重构为class="loader"，同时处理了id="page"的元素。

动画层

关键帧有点棘手，但我最终选择将动画隔离在它们自己的新第五层中：

1

@layer reset, base, layout, components, utilities, animations;

为什么将动画放在最后一层？因为动画通常是最后运行的，不应受到样式冲突的影响。

布局层

.page选择器也存在与ID相同的问题，由于我们之前在HTML中修复了它，我们可以将其修改为.page并将其放入layout层：

1
2
3
4
5


@layer layout {
  .page {
    display: none;
  }
}

自定义滚动条

滚动条是跨网站持续的全局元素。这可能是一个灰色区域，但我说它完全适合@layer base，因为它是一个全局的默认功能。

导航和组件

导航元素很直接，因为它是定义导航栏位置和尺寸的主要结构容器。它应该进入layout层。

徽标、导航列表、按钮等可重用UI部分属于components层。

媒体查询

媒体查询应该有一个专用层（@layer responsive），还是应该与它们的目标元素在同一层中？我最终选择了后者。

我的推理是，将它们保持在一起：

将响应式样式与其基本元素样式保持在一起
使覆盖可预测
与现代Web开发中常见的基于组件的架构很好地配合

工具层

我们还没有接触utilities层！我保留这一层用于设计用于特定目的的辅助类，比如隐藏内容——或者在这种情况下，有一个.noselect类非常适合。它有一个单一的可重用目的：禁用元素上的选择。

挑战与收获

重构过程并非一帆风顺：

确定起点困难：对于现有项目，很难确定从哪里开始
浏览器支持问题：层叠层目前有94%的支持覆盖率，但可能需要支持不支持分层样式的传统浏览器
媒体查询定位不明确：媒体查询的最佳位置需要仔细考虑
!important关键字处理复杂：它们反转整个分层优先级系统

层叠层的帮助（和局限）

建立层无疑改善了代码。真正的胜利在于更可维护的样式集。更容易找到你需要的内容，了解特定样式规则的作用，以及在哪里插入新样式。

同时，我不会说层叠层是银弹解决方案。请记住，CSS本质上与其查询的HTML结构相关联。如果你正在处理的HTML是非结构化的并且存在div滥用问题，那么可以肯定地说，解开这种混乱的努力更高，并且同时需要重写标记。

结论

为层叠层重构CSS绝对值得单独进行维护增强。从零开始定义层可能"更容易"，因为需要排序的继承开销和技术债务更少。但如果你必须从现有代码库开始，你可能需要先解开样式的复杂性，以确定你需要进行多少重构。

通过这种系统的方法，我们成功地将一个真实世界的项目完全重构为使用CSS Cascade Layers，创建了一个更模块化和可维护的CSS架构。

深入解析CSS层叠层在现有项目中的集成实践

本文详细介绍了如何将CSS Cascade Layers技术集成到现有遗留代码库中，通过实际案例演示了从分析项目结构、规划层级到具体重构的完整流程，涵盖了特异性管理、媒体查询处理、动画集成等关键技术要点。