CSS 关于雪碧图预处理和后处理方案的讨论

广告：SF 里弄了个 CSS 小圈子，欢迎一起来讨论问题

前端小图标处理方案众多，本文主要介绍基于雪碧图的处理方案，分析雪碧图的预处理和后处理模式的得与失，以及在项目中通常会遇到的问题以及解决方案。其他小图标处理方案未在此文探讨之列。

此外，本文更多的是理论性分析，具体技术实现不作深入解释。如有疑问，欢迎到上述小圈子一起讨论！

讨论的起点是工程工具 Gulp/Webpack 上的集成方案（手动拼合雪碧图的做法已经作古了）。

1. 预处理方案

代表：gulp.spritesmith 和 webpack-spritesmith

预处理方案是预先指定需要生成的雪碧图切片元素，由工具合成后，得到相应的雪碧图和数据 (S)CSS 文件，开发中将二者投入使用。

数据文件内容通常是可定义的，我们可以自定义模板或者内容生成函数（怎么写这里就不探讨了）。借助 SCSS 等 CSS 预编译语言的威力，如何使用雪碧图数据就极具便利性。

注意，下面的 SCSS 代码都是写的模板函数生成的内容，模板函数具体怎么写不在本文探讨范围内。

最简单的，我们可以直接生成类（如），如：

.icon-home {width: 12px;height: 12px;background: url(sprite.png) -56px -48px no-repeat;
}

这样在 HTML 结构中可以直接使用。但如果切片元素众多，每一条规则都要有单独的 background 属性的话，未免太冗长，稍微改进下，把公共的 background-image 属性提取出来（高清模式下还有 background-size，以下从简讨论），可以生成这样的内容：

.icon-home {width: 12px;height: 12px;background-position:-56px -48px;
}
.icon-back {width: 18px;height: 20px;background-position: -10px 0;
}
.icon-home,
.icon-back {background-image: url(sprite.png);
}

但是，如果有的类没用到，白白生成一个类岂不是很没必要？或者我们不想使用 .icon-home 这样子的类名，那我们用 SCSS 占位符可以解决这个问题：

%-icon-home {width: 12px;height: 12px;background-position:-56px -48px;
}%-icon-home,
%-icon-back {background-image: url(sprite.png);background-repeat: no-repeat;
}

然后需要用到的时候，再继承这个占位符：

.head-home {@extend %-icon-home;
}

这样，我们就能用上自定义的类名，并节省 CSS。

但如果遇到状态性变化怎么办？比如 :hover 时小图标变红，这时候其实除了 background-position 改变外，其他数据是没有变化的。

按上述方案，我们的写法会是：

.head-home {@extend %-icon-home;&:hover {@extend %-icon-home_hover;}
}

生成的最终 CSS 是：

.head-home {width: 12px;height: 12px;background-position:-56px -48px;
}
.head-home:hover {width: 12px;height: 12px;background-position: 0 0;
}
.head-home,
.head-home:hover {background-image: url(sprite.png);
}

思索发现，本质上占位符只是包含了图片信息，那我们换一种更加高端点的写法：

// 把雪碧图数据保存为一个 SCSS Map 数据
$__sprite__: ('home': ('width': 12,'height': 12,'x': 56,'y': 48,'url': 'sprite.png')，'home_hover': ('width': 12,'height': 12,'x': 0,'y': 0,'url': 'sprite.png')
);// 公共部分依然占位符
%-sprite-common {background-image: url(sprite.png);
}// 输出 background-position
@mixin sprite-position($name) {$data: map-get($__sprite__, $name);$x: map-get($data, 'x');$y: map-get($data, 'y');background-position: -#{$x}px -#{$y}px;
}// 输出其他切片元素私有数据
@mixin sprite-item($name) {// 继承公共样式@extend %-sprite-common;// 设置独有样式@include sprite-position($name);$data: map-get($__sprite__, $name);$width: map-get($data, 'width');width: unquote($width + 'px');height: unquote(map-get($data, 'height') + 'px');
}

生成出以上 SCSS 模板后，我们就可以这样使用雪碧图了：

.head-home {@include sprite-item('home');&:hover {@include sprite-position('home_hover');}
}

生成出来的效果类似于：

.head-home {background-image: url(sprite.png);
}
.head-home {background-position: -56px -48px;width: 12px;height: 12px;
}
.head-home:hover {background-position: -0px -0px;
}

这样，在 :hover 态下生成的 CSS 规则只会包含必要的变动。

总结起来，预处理模式的优点在于，通过自定义 CSS 数据文件，可以随心所欲地使用已经生成出来的雪碧图信息。

然而，在预处理模式下，开发的页面依赖的是生成后的雪碧图，而不是合并前的雪碧图切片元素，随之带来的问题是：没办法实现雪碧图的按需合并。

预处理方案一般以页面为单元组织雪碧图。思考这样的问题：如果一张雪碧图对应一个页面，那各页面的公共组件使用的雪碧图，是每个页面各一份副本，还是只保存一次切片元素，把通用的抽成一张公共雪碧图呢？

如果各存一份，公共组件的切片元素就得保存到多个文件夹，每次更新、删除、添加的时候得同步多处。如果管理不当，就会导致页面元素不同、废弃的切片仍被合并以及遗漏等问题。（以 CSS 文件为单元组织雪碧也会遇到类似的情况。）

如果抽成一张公共雪碧图，假设一个最简单场景：有 ABC 三个页面，其中 AB 页面有一个共同的切片元素 ab.png ，BC 页面也有一个共同的切片元素 bc.png。这两张切片元素都放进了 spr_common.png 中。由于静态资源管理需要，我们在打包的时候统一给资源加上签名，也就成了 spr_common.de353d.png。现在，需要更新 ab.png 这张切片，进而变成了 spr_common.5ef25d.png。而 C 页面的样式里包含了这张雪碧图，尽管自身没有任何变动，但由于公共雪碧图变了，C 页面的 CSS 也必须跟着变化。即，公共雪碧图会带来耦合问题，局部页面更新会造成其他页面不必要的跟随变化。

后处理方案则解决了这些问题。

2. 后处理方案

典型：postcss-sprites

后处理方案通过对已经生成的 CSS 文件进行分析，将其中包含切片元素的 background 或 background-image 作为依赖收集，合并成雪碧图后再将相关参数替换。

如上述典型工具，生成前是：

.comment {background: url(images/sprite/ico-comment.png) no-repeat 0 0;
}
.bubble {background: url(images/sprite/ico-bubble.png) no-repeat 0 0;
}

生成后是：

.comment {background-image: url(images/sprite.png);background-position: 0 0;
}
.bubble {background-image: url(images/sprite.png);background-position: 0 -50px;
}

如此一来，CSS 中有哪些切片元素就合并哪些，不会把没有用到的切片也合并进去。即一张 CSS 样式表有一张专门的雪碧图。

不过，正如上面所看到的，后处理模式解决了按需合并的问题，也不会造成页面/组件间雪碧图的耦合，但却丧失了预处理方案中直接利用数据的便捷性。在预处理方案中，我们不用人工地去衡量切片元素的宽高，而是让 SCSS 自动输出，后处理方案却做不到这一点。

3. 预处理和后处理相结合

既要能像预处理那样不用人工的地去量切片，又要像后处理那样实现按需的合并，这就是我理想的开发模式。

基于以上探索，我写了个工具：postcss-sprite-property 来实现二者的平衡。做法是：

区分开发环境和生产环境。在开发环境中，不合并雪碧图，直接使用切片元素预览；生产环境中，为每一张样式表内的切片合并雪碧图
利用 node-sass 所支持的自定义函数功能，为 SCSS 注入 image-width 和 image-height 两个自定义函数，用来查询图片宽高数据
使用 @sprite-item 和 @sprite-position 两个混合，优雅地定义一张雪碧图元素
尽量为公共属性生成一个公共的规则
Webpack 中，开发时不拼合雪碧图，让切片本身作为组件依赖；打包时合并雪碧图并剔除切片元素

来看一个实例：

我们把如下样式放进我们的公共样式库中：

// 使用雪碧图
// 以图片名作为参数
@mixin sprite-item($name) {// 统一一个路径存放切片元素// 这样就能得到图片的实际地址了$url: '../asset/sprite/#{$name}.png';// 注入的 `image-width` 函数可以帮我们查询图片宽度$width: image-width($url);@if (null == $width) {@warn 'Sprite element `#{$name}` not found!';} @else {// 获取图片高度$height: image-height($url);// 自动书写 `width` 和 `height`width: $width;height: $height;// 定义背景// 开发模式下直接按输出预览// 生产环境下将其替换为雪碧图的数据background: url($url) 0 0 / #{$width} #{$height} no-repeat;}
}
// 改变雪碧图 `background-position`
// 和上面的 `sprite-item` 区别仅在于
// 这个混合不输出 `width` 和 `height`
@mixin sprite-position($name) {$url: '../asset/sprite/#{$name}.png';$width: image-width($url);@if (null == $width) {@warn 'Sprite element `#{$name}` not found!';} @else {$height: image-height($url);background: url($url) 0 0 / #{$width} #{$height} no-repeat;}
}

现在，具体项目里就能这样使用了：

.home-head {@include sprite-item('pageA/home');&:hover {@include sprite-position('pageA/home_hover');}
}.home-back {@include sprite-item('pageB/back');
}

开发阶段，没有合成雪碧图，直接使用切片预览，所以效果是这样的：

.home-head {width: 12px;height: 12px;background: url("../asset/sprite/pageA/home.png") 0 0 / 12px 12px no-repeat;
}
.home-head:hover {background: url("../asset/sprite/pageA/home_hover.png") 0 0 / 12px 12px no-repeat;
}.home-back {width: 18px;height: 20px;background: url("../asset/sprite/pageB/back.png") 0 0 / 18px 20px no-repeat;
}

最后发布生成的样式则是这样的：

.home-head {width: 12px;height: 12px;background-position: -56px -48px;
}
.home-head:hover {background-position: 0 0;
}
.home-back {width: 18px;height: 20px;background-position: -10px 0;
}
.home-head,
.home-head:hover,
.home-back {background-image: url(sprite.png);
}

当然，如上所示，.home-head 和 .home-head:hover 都在最后的公共规则中。最理想的当然是没有更好，但作为一个平衡方案，这仍是可接受的。

更具体的用法和更多的功能请参看 Github：https://github.com/HaoyCn/pos...

4. REM 布局中雪碧图的错位问题

这个算是雪碧图的硬伤。其他小图标方案不会有这个问题。REM 布局里雪碧图错位几乎是不可避免的，在安卓下错位甚至可以达到 2px 左右。我也总结出一个 CSS 兜错方案：

background-position 使用百分比单位
给雪碧图增加透明内边距，如 spritesmith 工具设置 padding: 8

增加 1-2px 的容错区域，概要代码如下：

%-sprite {// 错位时的容错区域padding: 1px;// 从内容区开始绘制背景background-origin: content-box;// 在内边距盒外裁切背景background-clip: padding-box;
}

利用以上三个属性的组合来腾出容错的空间。

4. 结语

关于雪碧图的处理方案的讨论就到此结束了。待 HTTP2 普及之后，也就没有雪碧图什么事了，而现在仍有其存在的必要性。

处理小图标还有其他的方案，如 Iconfont 和 Svg-Sprite。总之没有最好的，只有最适合的。

感谢阅读。欢迎来文章顶部的小圈子一起讨论！