一、从哪里开始...
几年前我写过一篇非常实用的文章，介绍了一项非常有创意的技术：《CSS背景色镂空技术的实际应用与进展》。 为了更容易控制图标图形的颜色，对图片进行了镂空处理。 加工。 例如下图（点击有随机背景色）：
因此，我们只需要一组图片就可以实现各种色彩效果！
而不是收集各个州的完整葫芦七兄弟，如下所示：
不仅节省了图片资源的大小，CSS镂空图片技术还有一个好处，因为我们图标的颜色是由CSS属性控制的。 为此，我们可以逐渐使用transition来实现过渡效果，让交互更加圆润。
说到用CSS控制图标的颜色，我们自然会想到iconfonts，或者使用SVGsprites技术，或者使用混合模式来实现。
但也存在不足，例如：
SVG的兼容性以及混合模式的理解成本和环境约束等。
为此，转身之后你会发现，有时候，画面才是最真实的。 下面我们来看看demo的疗效。 即使是用background-image实现的，并且用文本hovertransition来过渡hover状态和选中状态，这也是传统背景图片做不到的。
一条线：
transition: background-color .25s;
可以让互动看起来很饱满！
只需一组图片即可完成默认、悬停和选定三种颜色状态（见右图）。 看上去非常不错，简直好到飞起来。
但是这些实现都有一个致命的缺点，就是CSS的加载和背景图片的加载不同步，尤其是第一次加载图片时，图片是异步的，有明显的延迟，所以我们会看到颜色极其难看的方块瞬间出现（可以用力刷demo来体验）！
俗话说“开发可忍，设计不可忍”，这些问题看似很严重，直接导致这种看起来很酷的方法濒临夭折，而且似乎只适用默认情况下隐藏的元素。
别慌，有我在！
2.解决base64url图片和异步色块问题
这很容易理解。 就是将背景图片转换成base64url图片。 由于是集成在CSS文件中，所以基本是同时呈现，没有色块。 但该方法有明显的局限性，即仅适用于一些规格较小的小图像。 与之前demo的背景图类似，大小超过5K，直接嵌入到CSS文件中。 它就像体内生长的囊肿，体积太大，但base64渲染的成本相对较高。 图片越大，速度越慢，而且IE7浏览服务器很难支持base64图片。
所以，这个方法在这里不适用，难道我就必须死吗？ 不！
3.解决contenturl图片和异步色块问题
六年前，也就是十年前css 背景图大小，我在《CSScontent内容生成技术及应用》一文中首次介绍了CSScontenturl图像内容生成技术css 背景图大小，即可以将前后伪元素直接插入到图像中。 请注意，它是直接图像。 不是元素的背景图片，句型如下：
.demo:after { content: url(xxx.png); }
OK，如果你观察过页面图片的加载，应该会注意到这样一个现象，即图片如果没有通过HTML属性或者CSS值来限制width/height，在浏览器获取到原始图片之前图片的规格，图片占用的空间大小为0。如果我们浏览新浪微博，我们会发现页面的高度在逐渐降低。 导致页面布局重绘，影响加载性能。
然而，存在必须有一个理由。 这里，我们可以利用图片加载时占用0空间的特点来防止出现色块的问题。 怎么解决呢？ 就是将元素的background-imageurl值改为伪元素的contenturl值； 同时将background-position定位改为其他定位，比如相对定位，如下代码所示：
.icon {
width: 140px; height: 140px;
background: #c8c8c8 url(icon.png) no-repeat 0 -140px;
}↓.icon { /* 注意，只设高度不设宽度 */
height: 140px;
background-color: #c8c8c8;
overflow: hidden;
}
.icon:after {
content: url(icon.png);
position: relative;
top: -140px;
}
红色注释“只设置高度不设置长度”指出了实现的关键：
页面渲染过程如下，1.CSS加载； 2.对应DOM渲染，出现背景色； 3、拉取DOM样式对应的背景图片。
传统的实现是2到3出现问题，重新向服务器请求图片，造成时间差和色块。 但我们这里的实现是不同的。 当我们的背景色出现，但是图片没有加载时，因为我们的CSS没有设置元素的长度，而图片没有加载的特性将长度抢占为0，所以完成在 2 3 的时候即将继续，我们整个元素的高度是140px，长度是0，长度是0！ 这是什么意思？ 表示元素不可见，即即使有背景色，但规范为0，我们也看不到一丝背景色的痕迹； 图片被请求后，自然会填充元素。 背景颜色也被遮盖掉。 没有时差，完美解决色块问题！
互联网浏览器 7
什么时代，IE7浏览器，如果你喜欢，可以用表达式表达，或者直接打补丁JS，我现在不愿意陪伴这个浏览器了！
4。结论
我测试了一下，发现在Chrome浏览器中时间差异其实更明显。 另外，旁边的contenturl有一定概率会有最后一个色块。 按道理来说，不应该。 现在已经太晚了，已经两点了。 我有时间研究研究。
第二天更新
在工作中我研究了为什么最后1~2张图片有一定的几率会出现色块。 我刷了几十次体验了一下，突然灵光一现。 最初，图片是从上到下加载的。 当有背景色时，仅获取图片规格。 然而，数据尚未完全下载。 因此，此时由于网络速度的原因，图片就加载完毕了。 底部可能未正确加载。 类似如下：
我之前已经介绍过，参见《渐进式jpeg（渐进式jpeg）图片及相关》。
哈，知道了问题的原因，就知道如何解决了。 PS保存图片时，JPG是连续的，而PNG是隔行的：
我把原来的图片替换掉了，现在真的不会有一点色块了。
现在的小问题是如何在保持隔行扫描的同时处理 PNG 压缩。 等一下，我去研究一下~
更新于 2016 年 2 月 28 日
假期期间做了一些研究，一些压缩工具，甚至Fireworks，都没有听说png8alpha格式同时支持隔行扫描模式。 大神在民间，希望有知道如何处理的男同伴不吝赐教！
PS：演示背景图现在替换为png8alpha压缩图片，节省了一些流量~
发表评论