logo
当前位置:首 页 > 编程技术 >前端技术 > 查看文章

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

讨论的起点是工程工具 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。总之没有最好的,只有最适合的。

一个有大大梦想但是没有支撑这梦想的技术的攻城狮,大家就当这个博客是你的技术工具箱吧,我会吧我工作中遇到的问题贴在这,大家需要的记得把我放到收藏夹哦! 百度输入“子傲代码”就可以了

—— 陈子傲

admin
众说纷纭Comments
大眼 可爱 大笑 坏笑 害羞 发怒 折磨 快哭了 大哭 白眼 晕 流汗 困 腼腆 惊讶 憨笑 色 得意 骷髅 囧 睡觉 眨眼 亲亲 疑问 闭嘴 难过 淡定 抗议 鄙视 猪头
小提示:直接粘贴图片到输入框试试
努力发送中...
footer logo
未经许可请勿自行使用、转载、修改、复制、发行、出售、发表或以其它方式利用本网站之内容
Copyright ©ziao design Studio All Rights Reserved.沪ICP备14052271号-3