html5 和 css3 里有 css sprite 的替代品吗

Nope.
Optimizing is for now, not the future.

从你的设备支持状况来考虑, 尝试下 base64+dataurl 来载入 icon

css sprite 只是一种 trick，连 technique 都算不上。只是用很反人性的方式、增加工作量为前提来减少请求数。
至于新标准，更多的是为语义化和便捷开发做优化，性能不是标准制定者们该考虑的问题。

说了半天，其实应该叫：CSS Sprites。

今天看了一些html5的文章，感觉有一些新规范实际上是把原来就流传于开发者间的山寨技巧标准化了，所以忽然想起悲摧的Sprites哈哈。

dataurl不错

No more CSS Sprites, Data URI + MHTML please.

不知道楼上2位是否真的将data URI投入实际使用，至少在我看来有几个严重问题：
1.base64编码会增大1/3体积。
2.无法让浏览器缓存图像，只能缓存引用它的文件。
3.在HTML上不能复用，要复用只能放在CSS和Javascript里。
4.你如果把背景图片写在CSS或Javascript里，你在下载完CSS和Javascript之前，浏览器是完全停止解析和渲染的，而常规的引用外部图片的方式是可以并行下载的。

@keakon
1. data uri是用文本来保存图像，虽然体积增加，但是文本可以用gzip进行传送，基本能压缩1/3的体积，有些时候甚至更小
2. 虽然不能缓存，但是缓存在外联的的文件中基本能代替缓存。外联文件更新的时候需要从新下载是个问题
3. 这个是一个问题，但是在css sprites的使用情景里，基本都是css
4. 这个缺点css sprites一样存在

@chone

1.我们使用的图像大部分就是压缩过的，如果base64后再gzip会变得更小，那么这个图像压缩算法就太傻了。
拿http://www.google.com/images/logo.gif来说，原大小是11430字节，base64后是15240，再gzip是11473。
而且你测试下就知道，多一次compress和decompress的操作，肯定会对性能造成影响，更何况你还是用在CPU不给力的手机设备上。

2.如果要缓存，就必须每个图片写一个css。而获取这个文件本身就相当于多了一个HTTP请求，没有起到减少HTTP请求这个目的。

4.这个是和1相关的。一般的css文件只有几k到几十k，是很容易下载完的，不需要等待太久。而你加上了图像后，css变成了几百k甚至上m，这对用户来说就很慢了。因为我可以忍受图片暂时不显示，但不能忍受整个网页都暂时不能显示。

强烈关注各位的观点阐述，很有意思。

@keakon 如果你一味比较两方技术的优劣的话，反而让我质疑您“是否真的将data URI投入实际使用”。
就我个人经验来说（虽然并没有多少，如有不足请指正），Data URI + MHTML 只适用于小尺寸、同时具有高度复用性的图片，比如 h1~h6 的背景图，或者最近一个项目中我用它存储 faux 背景。如果图片（Riot 之后）的尺寸大于 5K，我是坚决不用 Data URI + MHTML 的。

对我个人而言，CSS Sprites 是个很反人类的东西，维护起来的难度对前端和视觉都是折磨，如果你现在不这么觉得，等半年以后给一个上 k 高度的 Sprites 加几个像素的时候就知道了。而且更新完之后，要在服务端同时清掉 CSS 和那张 Sprites 图的 cache，麻烦至极。

最后再说一个非常偏执的想法：我对所谓的性能优化和种种压缩厌恶至极，创造力和灵感不该被这些桎梏所束缚。如果你想创造美好的东西（仅指 web），永远不要把性能优化的优先级排在前面。甚至有次我直接问 @maxvoltar 说有没有好用的 CSS 压缩工具，这位大牛直接回复我说：Never used that before.

技术本来是为人造福的，合理的讨论有利于大家共同进步。如果还有争执，一位经验丰富的前辈已经说的够清楚了，请静心阅读：
http://dancewithnet.com/2009/08/15/data-uri-mhtml/

题外话：如果不是需求方要求照顾 IE，我死都不会用这些东西。4行 CSS3 搞定。

@disinfeqt

就我本身来说，我没有采用上述的任何一种技术，因为我觉得简单就是最好的。我甚至完全不考虑IE浏览器，我自己的博客就是HTML5 + CSS3。

小图像下载本身就很快，拼在一起并没有让我感觉到更快。对用户来说，它们是次要的，关注的重点应该是内容本身。

而data URI会增大CSS体积这个缺点对我来说是致命的。这种次要内容绝对不应该影响到用户正常浏览网页，而CSS在下载和解析过程中对浏览器的独占性决定了它必须尽可能简化和轻量。
单个5kb的文件看上去是可以接受，但整个网站会用到多少个这种图片呢？如果就3、4个，增加几个HTTP链接又不会怀孕；如果10几20个，我想这个CSS也就不可接受了。
而且从维护上来说，看到一堆乱码一样的东西，人脑是不可能读懂这是什么图片的。

举个很现实的例子，我手机用的是GSM，网速慢得要死，所以我是不显示图片的。可你如果放在CSS里，我就被迫去下载这些我不关注的玩意了。

我还见过一些体验很差的网站，打开后先展示一个框架，然后下载半天资源，过了30秒才给你展示最重要的文字内容。
我想你必然更愿意在3秒内看到主要内容，然后花27秒去下载其他资源。至少在这个等待过程中，你可以看到想看的内容，而不是一个空白的框架。

我认为它真正有意义的地方是用来生成验证码。这个玩意不需要在服务器端生成和维护一张临时图片，这对于不能更改文件系统的GAE来说是很有意义的。

OK I'm exhausted. Topic is off.
Oh btw, by "blog", you meant http://www.keakon.cn/bbs/forum-8-1.html ?
It's delightful, mate.

这个是旧的，下个月主机到期就会自动转到GAE了，因为有些文章还在整理中，所以地址就懒得公布了

演示在这里（版本比较旧）：http://acgpedia.appspot.com/blog/

你们讨论的应该大多是把css sprites用在小图小按钮之类的地方

我自己的单页主页 http://pudd.cc

是把七八张中大型图片合成一张了(￣￣")光下载图片就可能要十秒，也没见过有多少网站用过这么大的css sprites，所以不知道自己是不是做了一个很不地道的东西出来。

@keakon 用CSS sprite做验证码。这招学到了。太高科技了。

不回答布丁的问题

我觉得闲得OO疼的时候才会去捣鼓一下CSS Sprites，对于MiniSite来说拼一拼还是挺有趣的：
http://bgm.tv/tokei
http://chii.in/img/tokei/tokei_spirit.png

@Sai 可以再优化一下把颜色相近的放在相邻区域，有利于浏览器渲染

@pudd
速度还不错，很漂亮，建议导航栏加个title属性，不加文字说明的话，有些图标不知道代表什么。

这里css sprites的应用感觉并不恰当，还记得它的本意吗减少HTTP连接数，加快下载速度。
可是你的all.jpg有500多k，我花了5秒才下载完，这时候一直都只能显示load.gif。
事实上让用户第一时间看到第一张图，在用户还在摸索你的导航条时偷偷完成其他几张图的下载更合适。

另外，blog的响应速度很慢，感觉应该是被数据库拖慢了。

@keakon 谢谢keakon～因为最开始的方案就是一张图一个独立的连接，但是发现鼠标在下面的导航按钮上游荡时上面的图就切换得非常迟钝，所以尝试改用了css sprites，虽然第一次读图时花的时间比较多，但是读取完毕后就无比顺流。

一开始就载入第一张默认图片其他图交付后台下载这个很有趣，有点像iOS app启动的原则，先放上一张跟app界面相似的静态图片去骗人哈哈哈哈。

@key4ever key君乱入！

@pudd
这个问题可以用Javascript解决，也就是预加载图片。
纯HTML+CSS也能做到，底部写个div来下载图片，但是隐藏显示就行了。