'Internet Explorer' 分类的存档

IE里behavior属性的一个小bug

我用的百优空间没有访问日志,所以我在K2模板的footer.php里加了一段代码,将每次访问的相关信息记录进一个文本文件里。这种方法的缺点是只能记录Blog页面的访问,其他的文件比如图片、js、CSS文件就没办法了。

这两天我的空间经常会提示数据库连接过多,而且垃圾评论也变得狂多。昨天修改了下这个插件,直接屏蔽所有全是英文并包含链接的评论。平常我很少看这个访问日志,只是每个月清理一下,以免影响速度。今天因为空间有问题,就去检查了一下,发现有很多对pngbehavior.htc文件的访问,有根目录下的/pngbehavior.htc,也有各个月份目录下的/2006/07/pngbehavior.htc,也有page下的/kfc/pngbehavior.htc。用WinRAR在我的网站备份文件里搜索了一下,发现CoolPlayer插件CoolPlayer插件的coolplayer.css文件里有"pngbehavior.htc"字样,具体的代码是:

img {
	behavior: url( pngbehavior.htc );
}

我对CSS了解不多,只记得CSS里background里会用到url,一般写成url(abc.png)表示和当前CSS文件同目录下的abc.png文件。而写成url(/abc.png)则表示网站根目录下的abc.png文件。写了个小html文件做测试,1.html文件里引用"/tmp/t.css"这个CSS文件,并加上一个div标签和一个img标签,img标签的src为"/mm.png",而CSS文件里写上:

img {
	behavior: url( pngbehavior.htc );
}
div{
	background: #FFF6BF url(haha.png) 8px 6px no-repeat;
}

把文件上传到网站上,开上IRIS嗅探器,在IE浏览器里输入这个html文件的地址。嗅探结果显示IE依次读取的是/1.html、/tmp/t.css、/pngbehavior.htc、/mm.png、/tmp/haha.png这几个地址。

也就是说,behavior里的url和background里的url还是有区别地,behavior的url不支持相对路径。写错了,behavior里的url不是不支持相对路径,是我的例子特殊了。behavior里的url的当前路径不是CSS文件的目录,而是当前页面的目录。也就是说,"/"目录下的html文件,"/tmp"目录下的CSS文件,background里的url使用的是CSS文件的当前路径"域名/tmp",而behavior里的url使用的是当前访问页面的当前路径"域名/"。bahavior属性好像只有IE支持,或许这是IE的bug?看访问日志里pngbehavior.htc文件的访问记录,User-Agent里有MSIE 6.0的,也有MSIE 7.0的,也就是说IE6和IE7里都有这个问题。

WordPress通过.htaccess文件接管访问,除了服务器上实际存在的文件外,其他的访问都被重定向到WordPress的index.php文件上。所以,这些对pngbehavior.htc文件的访问最终都会被WordPress处理,也就是说都会走一遍WordPress的整套程序,包括连接MySQL数据库、载入WordPress核心文件、载入插件、分析访问地址,最后给出HTTP 404。因为现在使用IE浏览器的人还是比较多的,所以对网站的性能还是有很大影响的,不仅占用了CPU资源,还增加MySQL连接数。而这个pngbehavior.htc文件,估计应该是为了解决IE无法处理png的alpha通道的问题吧,反正我也很少用Coolplayer,直接把这条CSS代码注释了事。

呃,目前CoolPlayer的最新版9.3版同样有这个问题。跟andot大大报bug去,啦啦~~

Update:最近接触到不少bug,包括IE的bug,Firefox 2.0里开发组非要在显示feed时只显示摘要,WordPress 2.1里开发组非要把以前feed里more标签无效改为有效。唉,这些关系民生,影响很多用户的事,怎么就没人管呢?IE也就算了,微软牛气嘛,这么多版本以来,哪个版本不能通过网页执行程序啊。Firefox和WordPress这样的开源软件也有这些问题,感觉开发组里没人为普通用户代言的,爱变成什么样就变成什么样。我越来越觉得WordPress不是我们普通WP用户的WordPress了,而是开发组的WordPress。

IE图片缓存bug

今天花了点时间调Blog的CSS。算起来,也有两个多月没怎么动过CSS了。

这次主要想解决下IE下显示的问题。因为我从去年3月以来一直用着Firefox,呃,上次开Maxthon是去年4月,所以没怎么在IE下检查过我的Blog。现在机器里没有Maxthon,想在IE环境下查看Blog就要开我的IE 6 SP2。可是,我的Firefox里设置了屏蔽51yes的统计代码,所以我每天在Firefox下看查看Blog不用担心51yes的统计数虚增。但是IE里没有屏蔽广告功能,所以,每次用IE进我的Blog时,我的内心都很挣扎。

文章内容部分的字体我又换回Verdana了。去年6月时详细地考虑了一下字体的问题,当时觉得宋体好点,尤其是标点符号的显示。比如“……”省略号,在宋体下显示在中间,而其他英文字体下只能显示在靠下的位置,类似六个点“......”这样。另外,引号和外国人名中间的间隔号也是宋体下好看一些。而字号,我用的是12px,觉得足够了。用了这么半年多,觉得宋体里英文的显示太不好了,显示的很小,不清楚,而粗体的英文,比如"W",简直就是一团黑。换回Verdana,则文章里的英文部分用Verdana显示。听说Verdana是微软特别找人为英文制作的,用来显示英文正文是最好的。而文章的中文部分则使用宋体。这里有点浏览器差异,在下一段介绍。整个CSS写成font: 12px/16px Verdana, 宋体, Sans-Serif;,显示效果还行。

浏览器的问题,Firefox是在字体列表中一次寻找,比如一个汉字,Verdana字体里没有,就往后找后面的字体,如果后面有一个楷体,就用楷体显示这个字。而IE和Opera,则是寻找一个有效自己,比如字体列表里第一个当前系统有装的字体是Verdana,就用Verdana显示文字,当遇到汉字Verdana里没有的时候,就使用系统默认的字体,而汉字的默认字体一般是宋体,所以汉字就被用宋体来显示。听说Vista里汉字的默认字体是微软雅黑,那么IE里我的Blog的文章正文部分应该就是以微软雅黑字体显示。不过我觉得微软雅黑不太好看,或许是不习惯吧。浏览器差异啊,真是个麻烦。

评论部分调整了一下,以前没注意CSS的匹配程度,导致custom.css里的评论CSS代码无法覆盖True Blue的CSS。现在评论部分好看多了。

True Blue 1.3.4是去年10月的事了,1.3.4_svn则是去年12月发布的,只是增加了在K2去年年底新增的TextTrimmer部分的CSS代码。这样算来,True Blue已经有4个月没什么变动了。到True Blue主页看了下,作者在Google Code建立了项目页面,1.4版已经在筹划中,现在已经beta 1了。1.4里做了不少改动,标题图片的显示方式换了,到时要重新用Photoshop制作我自己的标题图片了。

True Blue是用:before选择符对侧边栏里的每一个列表项进行处理的。在Firefox和Opera下可以看到效果,但是IE6里却没有效果,列表项前光秃秃的。原因当然是很简单,IE6不支持before选择符。我想在IE6下模仿Firefox下的效果,把Firefox下的页面截图,截取列表项前的标记保存成图片文件,然后通过CSS控制在IE下用该图片做列表项的标记。

很容易就做好了这件事,但是做好后却发现一个问题:侧边栏那么多列表项,每一个都要读一次图片,结果IE的状态栏上从“还剩160项”开始显示,半天才把这160多个图片下完。

在网上搜了一下,发现这是个很有名的IE的bug,叫做“IE图片缓存bug”。据这篇《IE缓存策略的BUG》里介绍,在使用innerHTML一次性添加多个相同图片的时候,IE不会使用图片缓存而重复多次读取图片。而且,微软网站也有一篇文章提到了这个bug,而这篇文章里则提到使用background-image一样会造成问题。唉,IE可真麻烦啊。

解决办法倒是有,通过JavaScript就可以。参考人家的代码写了一段js放在header.php里,刷新页面,却发现不起作用。或许,innerHTML里的图片和CSS里的图片还是有区别的吧。用IRIS嗅探发现,IE会先执行开头的js代码读取图片,然后再执行body里的js代码,最后再解析CSS,再读取160次那个小图片。

最终,没办法了,只有不用这个图片了。可恶的IE,○○××