前些天不知哪个feed反刍，看到老赵几年前发的这篇《意外得到了一个免费的HttpWatch Professional的License》，是不是在预示着什么？
今天向往常一样Google Reader，看到httpwatch 7.0搞发布活动HttpWatch 7.0: Spot the Differences!，于是就简单掺和了一下，没想到抢了沙发，license也到手了。
给httpwatch做个广告，原因嘛你懂的
7.0增加了4个新功能
2010-6-7正式发布，期待~
16
五 10
Data URI&MHTML: 用还是不用？
YAHOO!的性能专家Stoyan Stefanov先后发布了
- data:urls – what are they and how to use them
- MHTML – when you need data: URIs in IE7 and under
- Data URIs, MHTML and IE7/Win7/Vista blues
- Uncompressed data in base64? Probably not
NCZ也有
引起了我们对data uri的关注，国内的也有一些不错的文章，比如：
工作太过饱和一直未深究，而前不久YDN的Performance on Yahoo! Search for Earth Day再次提到，更是撩起了我内心沉睡的欲望…
data URI的优缺点
data uri的主要优点是减少了http请求数，Best Practices for Speeding Up Your Web Site：
Inline images use the
data:URL scheme to embed the image data in the actual page. This can increase the size of your HTML document. Combining inline images into your (cached) stylesheets is a way to reduce HTTP requests and avoid increasing the size of your pages. Inline images are not yet supported across all major browsers.
还有就是调用起来比css sprite更加灵活，缺点是增加了客户端的资源消耗。
浏览器支持情况
Most modern browsers support data URIs:
- Firefox 2+
- Opera 7.2+ – data URIs must not be longer than 4100 characters
- Chrome (all versions)
- Safari (all versions)
- Internet Explorer 8+ – data URIs must be smaller than 32k
不能太迷信权威，NET.2971 – The RFC 2397 data URL – Part 1这里说的比较靠谱：
2.3 – Maximum size
The size of data URIs is limited in some browsers. IE8 for example has a limit of 32,768 characters [4].
Filename Size[px] Size[kB] Size[chars]
Wallpaper_1600_1200.jpg 1600×1200 309 699052 – 9199 =A test was done with IE 8 (8.0.6001.18702), Firefox 3.5.3 and Opera 10.0. A large wallpaper, 1600×1200 px, 309 kB was converted to Base64, resulting in almost 690k characters. This inline image was added to a HTML page and opened in the browser.
IE8 only displays the first part of the image (probably 32,768 characters), Firefox and Opera are showing the complete image.
When searching for information about maximum data size, Opera is often mentioned with a limit of 4100 characters, but this is apparently for older versions.
It is often said that inline images should be limited to small images, for example icons. In practice, however, often much larger images are used. Examples are the Google news pages with 80×80 px standard images (about 3000 characters), some pages contain more than 20 of them. We also see that all modern browsers support large data URLs which is a deviation from earlier policies.
MSDN上的data Protocol：
Data URIs cannot be larger than 32,768 characters.
还有段视频Internet Explorer 8 Data URI（不想装淫光的下面有下载链接）
可以简单理解为我们只要把data URI的字符数控制在32768字符内就可以照顾到所有A级浏览器了。
IE6&7使用MHTML并注意MHTML在ie7/vista bug 解决方案就好了，JavaScript组件打包模式里说的比较明确：
MHTML在ie7+/vista缺少结束分割符无法显示，win03sp2缺少Content-Type会有安全提示，原因都MIME不标准，不是所有的东西都可以省。
下面要开始测试了，demo在此，是在WIN7 IE8的IE7模式进行的测试，结合httpwatch和fiddler，虽然不是测试所有浏览器但可以反映出一些共同的问题。
PS：demo是在tommyfan的基础上改的，节省了我不少时间，感谢囯＋先；99css所在的服务器大猫给开了gzip，有兴趣的朋友可以到 http://miao.in去看看:)
下载速度对比
正常网速
可见，base64稍慢
fiddler模拟低速
base64慢了不少
渲染时间对比
几毫秒可以忽略，不过还是base64偏慢，data:URI + mhtml troubles and solutions中有云：
data:URI takes much more time to be processed (in comparison to CSS Sprites or raw images) – about 10x more (for Firefox, for IE – 2x, for Opera/WebKit almost the same time). So in case of large images’ square (starting from 400×400, or 100k square dots), so you must be careful ibefore you completely convert all graphics to base64.
感官体验
并不是下载速度越快越好，还要考虑访问者的主观感受，比如逐步呈现(Progressiv Rencering)，将css放顶部的原因就在于此，测试demo，虽然放底部速度更快，但放顶部可以逐步呈现，详见《High Performance Web Sites: Essential Knowledge for Front-End Engineers》（中译名：《高性能网站建设指南》）第五章的分析。
sprite的demo中页面是逐步呈现的，而base64在css下载完成前一直处于“白屏”状态
Data URIs for CSS Images: More Tests, More Questions走了点弯路，想把data uri的css放底部，可能他没看过《High Performance Web Sites》吧:) (Rob, this is only a joke~)
文件尺寸对比
原始的31个icon加起来16.5KB
sprite的css 1.4KB + 图片4.54KB = 5.94KB
data URI的css 51.2KB, gzip后16.5KB
对于大型站点来说流量 = ￥，这点sprite领先
CPU&内存对比
通过观察Windows任务管理器，base64比sprite多1%左右的CPU，多1M左右的内存
data URI使用建议
- 能使用sprite的地方尽量使用sprite
- 不方便使用sprite的时候才使用data uri，比如
- 宽高不固定且又又要求background-position:center bottom
- repeat/repeat-x/repeat-y的图片
- png-24图片，IE6用α滤镜时图片请求不到会导致浏览器一直处于卡死状态，详见Image Optimization, Part 5: AlphaImageLoader，用mhtml代替则可避免此问题（先下载css，再从缓存调用自身）
以上结果跟demo本身的特点有很大关系，希望能看到各位的更多测试结果
除了文中提到的文章，下面的也不错：
- data URI scheme
- MHTML
- Inline Images with Data URLs
- data URI browser issues
- Why The data: URI Scheme Could Help Save Your Slow Site
- data: URL tests
- CSS + Data URIs = Fewer HTTP Requests
- К вопросу о кроссбраузерных Data URI （俄文，期待俄语达人能翻译一下，可以的话评论也翻译吧）
另外，我写了个生成器，改天详细介绍:)
25
四 10
IE font-family bug
三谈Web默认字体中有这么一段：
5. GB 编码问题。font: 12px sans-serif; 不设置宋体，页面为 GB 系列编码时，非中文操作系统下（港台用户中有不少英文系统，还有海外华人），IE的默认字体是 Microsoft Sans Serif Regular, 很难看。截图为证：
有两个解决方案：a. 用”宋体”垫底；b. 不加 sans-serif.
在同事的项目中也遇到过类似的问题，不过不局限于以上条件，详情如下：
- 出现在简体中文旗舰版Win7的IE8中（简体中文版XP的IE8正常），英文系统等未测试
- 页面为utf-8编码（http headers及页面meta中都已指定）
- css中是这么写的：
body{font-family:Tahoma,Helvetica,Arial,sans-serif;}而浏览器直接跳到了sans-serif
- 上面改为
body{font-family:Tahoma,Helvetica,Arial;}而当页面有一处为
a span{font-family:Arial,sans-serif;}mouseover前为sans-serif，mouseover后变为了Arial，太囧了
解决方法：推荐删去sans-serif，而用”宋体”垫底有时会不生效
某鬼佬遇到过另外的字体问题:《Euro symbol showing as serif font in IE7 when using bold Arial》
old9评论：
windows 下有一套映射缺失字体的机制，helvetica 会自动映射到 arial，可以在注册表里面找到这些东西：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes
发现Win7和XP还有些不同，截图留念，XP：
Win7：
顺便再复习下：
08
四 10
IE8 X-UA-Compatible 失效？
现在维护的项目中使用了
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >
来把IE8带入IE7标准，今天测试提出一个IE8下的小BUG，简单分析了一下，发现浏览器始终为IE8标准，并未切换到IE7标准（F12调出开发工具，文本模式自动勾选在IE8标准）
翻了下MSDN《定义文档兼容性》，里面有这么一句：
X-UA-compatible 标头不区分大小写；不过，它必须显示在网页中除 title 元素和其他 meta 元素以外的所有其他元素之前的标头（HEAD 节（可能为英文网页））中。
MSDN有机器翻译的传统，再看下英文版：
The X-UA-compatible header is not case sensitive; however, it must appear in the Web page’s header (the HEAD section) before all other elements, except for the title element and other metaelements.
而项目中是：
<head> <script ... <link href="xxx.css" ... <meta ...
杯具就这么发生了…
28
三 10
图文混排一粒
过需求时一不留神，很爽快的接了个如下图的效果：
条件及要求：
- 图片宽度及高度不固定
- 分享给好友贴底
- 照片描述及分享给好友左侧距图片10px
- 照片描述由后台控制输出字数
等做起来发现还挺折磨人，本想下周甩他们一句做不了完事，不过考虑 200,000,000+ P-people no jobs… 马上变得蛋定，上代码：
<!DOCTYPE html>
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<title>图文混排</title>
<link href="http://yui.yahooapis.com/3.0.0/build/cssreset/reset-min.css" rel="stylesheet">
<style>
.feed{margin:10px;width:500px;}
.feed-img{float:left;position:relative;#zoom:1;margin-right:10px;_margin-right:7px;}
.feed-img img{vertical-align:top;}
.feed-img .act{position:absolute;bottom:0;left:100%;margin-left:10px;white-space:nowrap;}
</style>
</head>
<body>
<div class="feed">
<div class="feed-img">
<img alt="犀利哥" height="430" src="http://img1.gtimg.com/cq/pics/29734/29734288.jpg" width="300">
<p class="act"><a href="##">分享给网友乡民</a></p>
</div>
<div class="feed-text">
<p>cool~</p>
</div>
</div>
</body>
</html>
——————– 补充提醒分割线 ——————–
评论前确保您已看过减小 HTML 文件
25
三 10
[视频]Object Oriented CSS by Nicole Sullivan
不建议在线看，速度太慢，建议FQ后下载：Object Oriented CSS by Nicole Sullivan（OGV格式，射手OK，QQ影音貌似不行）
19
三 10
css换行符对gzip的影响
之前做过一个css压缩工具CssOptimizer，其中一点是把换行符都去了，有同事反映这个做法过于极端，加上服务器端会进行gzip，这个换行符到底要不要去掉呢？于是拿了个项目中的文件简单测试了一下（css中的注释已去除）：
| 去除换行符 | 保留换行符 | |
|---|---|---|
| gzip前 | 46.4KB | 48.0KB |
| gzip后 | 8.40KB | 8.58KB |
可见，去除换行符对性能来说还是有好处的，不过前提是注意这些网站优化原则。