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

摘要：预处理方案代表和预处理方案是预先指定需要生成的雪碧图切片元素，由工具合成后，得到相应的雪碧图和数据文件，开发中将二者投入使用。预处理方案一般以页面为单元组织雪碧图。结语关于雪碧图的处理方案的讨论就到此结束了。

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

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

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

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

代表：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 也必须跟着变化。即，公共雪碧图会带来耦合问题，局部页面更新会造成其他页面不必要的跟随变化。

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

典型：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 自动输出，后处理方案却做不到这一点。

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

基于以上探索，我写了个工具：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...

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

background-position 使用百分比单位

给雪碧图增加透明内边距，如 spritesmith 工具设置 padding: 8

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

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

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

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

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

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