CSS 格式化工具

CSS 看起来简单到只需要几条查找替换规则就能重新格式化——在每个分号后加换行、在大括号内缩进——直到文件里真正出现嵌套、媒体查询,以及自定义属性和容器查询这类现代特性。基于正则表达式的方案对嵌套深度没有真正的概念,所以它无法正确缩进一个包含多个嵌套选择器的媒体查询,也没有办法区分一个结束声明的分号,和一个出现在字符串值或包含任意文本的自定义属性内部的分号。先把样式表解析成真正的结构——理解哪条规则嵌套在哪条规则里面,每个代码块从哪里开始、到哪里结束——才是让格式化在真实、非简单的 CSS 上也能正确工作,而不只是在玩具示例上工作的关键。

这个工具的压缩仅限于去除空白和注释——样式表里那些纯粹是给人读的、对浏览器渲染引擎没有任何意义的部分。它刻意不去合并重复的选择器、不重新排列声明,也不缩短颜色值(比如把 `#ffffff` 改写成 `#fff`),尽管一个更激进的压缩工具可以把这三件事都做了,产出更小的文件。这些改动可能会以容易被忽视的方式改变实际表现:合并两条选择器相同但写在层叠顺序不同位置的规则,可能会改变冲突时哪条声明胜出,重新排列声明也有同样的风险。单纯去除空白则没有这种风险——它不可能改变浏览器渲染出的结果,只会改变描述这个结果需要多少字节。

Web 服务器几乎都会在通过网络发送文本资源之前先用 gzip 或 brotli 压缩,这两种压缩算法都非常擅长利用空白和统一缩进所代表的那种冗余——重复的空格序列本来就压缩得非常好。这意味着一份格式化的样式表和一份压缩过的样式表,一旦都经过 gzip 处理,两者的差距会比未压缩时的体积差异所暗示的要小得多。压缩仍然有帮助,尤其是因为它会直接去掉注释而不只是压缩它们,但值得知道的是,现代工具链所承诺的大部分网络传输收益,其实来自压缩算法本身,压缩 CSS 只是在此之上贡献了一个较小的额外层。

格式化一份 Sass 或 Less 文件,意味着按原样对源代码应用统一的缩进和间距——嵌套、变量、mixin 和控制指令都保持完整,维持在它们原本的预处理器语法里。这和编译完全是两回事,编译会把变量解析成实际的值,把嵌套选择器展平成独立的纯 CSS 规则,并执行任何 mixin 产出它们展开后的输出。期待从 SCSS 输入得到编译后 CSS 的人,会惊讶地发现同样嵌套、带变量的源码只是被格式化了,而不是被解析求值了——这个工具是预处理器语言的格式化工具,不是它的编译器。