昨天我度过了自己难忘的25岁的生日，对于我而言，今年非比寻常。而对于浏览器世界也是如此——这个月我看了数份浏览器报告，欣慰地看到了Chrome的高歌猛进，Firefox的老当益壮，IE9的势如破竹，当然最最欣慰的，莫过于看到IE6/7的垂死挣扎，恍惚间幻觉三足鼎立之势已成。不过转念一看国内的情形却又让人沮丧，各种壳浏览器横行，前端革新之路仍相当遥远漫长。

在国外，究竟IE6/7被淘汰到何种地步呢？不足5%，甚至更低。看了今早smashingmagazine的关于兼容过时浏览器额外收费的统计，超过50%的开发者表示将额外收取费用，更有约1/3的开发者表示不提供兼容旧浏览器的服务，默认提供兼容的比例不足1/10——无论是IE6还是IE7，这些过时的古怪的浏览器实际上真的已经是奄奄一息。

如果时常阅读各种国外的技术类文章，另一种趋势也深刻的让你感受到IE6/7应该被彻底的埋了——作者们越来越少的谈论hack、谈论如何让新技术更好在旧浏览器上表现，更多的人开始无所顾虑的讨论日成气候新技术，仿佛IE6/7已经彻底消失了般。这样的一种脱节真心让人觉得蛋疼——当你看到一篇非常不错的文章，想着发散下思维应用在实际工作中却发觉完全用不到，然后时间久了渐渐淡忘的那种哭憋，也只有轻叹一声。

虽然很早以前我就放弃了对IE6/7的兼容，但每次想起过往岁月里和它们较真的日子还是有种莫名的怀念。里面包含了两种意思：技术更新的惆怅和实际收入的担忧，呵呵，这多么有趣。开发者一边喊着IE6快去死，一边缅怀着IE6的种种过往，难道不正是IE6带来了前端工程师的职位么？难道不正是IE6带来了页面重构的职位么？更直接的说：难道不正是IE6带来了一部分额外的难度上的收入么？

IE6本质上确实造成了一定前端入行的门槛，它让新手的知识结构混淆、不知所措——实则按照标准系统的学习，单单前端页面的东西，又能有多少？所以当标准开始真正大行其道的时候，我并不看好页面重构这样的单纯的CSS职业，CSS的路很短，即便有CSS3，甚至以后的CSS4，CSS5， 其内容永远恒定而且非常少——现在的CSS的内容是病态的，90%以上的内容来自各种兼容和trick，IE6和IE7的消失会直接导致这个职业的技术壁垒的瓦解。

所以开发者告别IE6/7的情感是复杂的，越是精熟这种感情便越不是滋味。IE6/7在国内的生命周期至少还有3年，甚至5年后都未必降低到现在国外的水平，这和xp系统的淘汰率直接挂钩。不过无论xp多么老而弥坚，我们终究要告别IE6/7，对我来说，应该就在今年了。

于是我打算聚集起自己这几年的hack知识，在今年年末写一篇年度文章，这里放个预告督促自己能够努力写完——我想这一定会是一个相当漫长的过程。我打算用这种方式，送别曾经给予我众多挑战的IE6/7。

任何一个开发者都应该爱IE6，无论我们日常如何抱怨。10年荏苒，IE6带给开发者的，是出其不意的“惊喜”，以及岁月流过的痕迹——里面有汗水，有苦恼，当然也有欢笑。数年之后，如果我还是一个前端工程师的话，我一定会津津乐道地说起IE6，一个调皮的小家伙，让我的工作充满了苦憋的乐趣。

**2011-11-09更新：**没有想到这么一篇无关痛痒的博文会被转到了cnbeta，作为一个天天在Reader上刷cb新闻的人来说，看到自己前几天刚刚写的标题是何等窘迫... 当然我不是故意找喷，不过既然被挂到了cb上就难免被喷了。不过对于文中的一些可能让人误解的地方，还是要澄清一下。

1. 对于CSS的内容90%的内容来自trick，我指的是知识内容。浏览器如果都标准，我相信任何人都能在1个月里掌握CSS的绝大部分，可如今一年对于一个CSSer可能都是很短的时间。我们很少写hack，我甚至不写宁可在布局或者实现上妥协，但是，我们的知识结构里，却不是这样——正因为庞大的各种兼容信息的存在，我们才能绕过很多坑不是么？
2. 我不认为页面的重构就此完结了，但页面重构的巅峰已经过去，留下的是渐渐贬值之路。单纯的页面原型重构是有极限的，CSS的知识量也非常非常有限，未来的前端工程师的技能里，CSS的比重一定会很低——更多的综合的东西需要掌握，UE，Marking等等，当然还有越来越难缠的JS。
3. 此文只是我的一些个人感想，无关痛痒。今天看了下GA里的数据，我的网站的IE6/7的比例都低于4%，Chrome占比超过50%，对于我的小站而言，IE6/7已死，也尽然是一个事实。

IE的透明滤镜bug算的上是IE为数众多bug里的不起眼的角色，直到之前我确实的遇到了它，我想我根本不会去关注非标准的IE滤镜带来的各种问题。这个bug的表现非常的直观，filter透明度渐变后，图片的某些点变成了透明的了！比如如果这个时候背景是白的，就是白色的噪点。这在banner切换时表现的非常明显——渐变是产生噪点，渐变完成后噪点也会一直残留：

这个Bug在IE6 7 8里都存在，实际上只要使用了透明滤镜就会表现出来，并且非常有趣的是，它只对一种颜色值有反应：#02050a

为什么是这个颜色？恐怕只有微软才知道。一开始我只是以为只有一些偏黑色的图片会出现这样的情况，但后来经过一系列测试我才发现原来出现的噪点如此固定以至于所有噪点所在的像素点原来的色值都是#02050a，决然不是巧合。然后，如果google这个"#02050a"，就能找到关于它的各种文章了，可以说这个色值就是这个bug的关键字。

原因是IE6 IE7 IE8在对JPG图像应用透明滤镜时，会将特定色值#02050a的像素点转换成完全透明的点。仅限于JPG图像，PNG以及GIF并不存在这个问题。目前，这个经典bug微软并没有什么解释，对于偶然遇到这个问题的解决方案也就无非下面几种：

• 不使用JPG，当然很多时候必须使用。
• 在图像中避免色值#02050a，这又是比较难做到的，因为JPG压缩造成的色值抖动无从控制，而偏偏JPG又是bug的一个成因。要避免使用到这个色值唯一的做法可能是用色阶把图片稍微调亮一些。
• 调整图片的背景到色值#02050a，这样做的目的是透明化的像素直接看到的是背景，多少可以避免一些视觉上的影响
• 停止使用滤镜，这点似乎也不可能，但至少我们可以在渐变结束之后移除滤镜，而不是任其停留在 alpha(opacity=100) 而无所作为。这样做的好处是，可以保证图片在渐变结束之后，不再显示残留的噪点。obj.style.filter = '';

实际上，黑色图片的使用本来就相对较少，所以可能永远都不会遇到这个问题。但是一旦遇到，#02050a就会像灾星一样跟着你让你觉得很不舒服。

最后，在我的测试过程中还发现了一个有趣的现象：无论是在一开始还是在bug产生之后，使用浏览器的缩放，即Ctrl + 然后 Ctrl -，或者按住Ctrl滚动滚轮，那么这个bug就会自动消失！并且在页面刷新之前都不会再存在！

就在几天前，WordPress宣布在最近一次的更新里不在支持IE6，这一举措加速了IE6的死亡。虽然我的博客早已经在顶部挂起公告，希望IE6和IE7的用户能升级他们的浏览器，但其实仍然安分地继续做着尽可能的IE6兼容。不过这次真的打算放弃了，既然连wordpress都宣布了不支持IE6，维护者也不应该拘泥下去，尽管我的wp版本始终是2.9.3...

IE6是伟大的，2001年8月发布，到现在10年时间，寿命之长恐怕真的是要空前绝后了。虽然web开发者对IE6深恶痛绝，但同时却也不能忘记IE6给开发者带来的价值——它曾经一度提高了web开发的门槛，虽然幅度有限。所以前端对IE6的感情是复杂的，失去了眼中钉的同时，也失去了一个挑战的舞台——IE6总能给我们惊喜，不管那惊喜是不是我们想要的——当然通常不是。

国内的IE6仍然是大多数，虽然系统升迁win7导致IE8也不少，但若要国内的网站放弃IE6远远还不够——甚至我自己的系统里就是IE6。根据5月份sitepoint的浏览器市场份额报告，IE6的比例已经下降到了4.37%，不过在国内恐怕在这后面加个数字都不止。其他IE版本里，IE7占9.78%，IE8占30.20%，IE9占0.75%，可见正常情况IE8才是最为流行的IE

我的网站IE占比34.57%，其中IE6占比23.22%，也就是说，我的网站IE6占比7.73%，其实比例也已经相当低。

至于IE7，虽然相对于IE6有所改进，但遗憾的是其引入了很多新的问题，导致往往IE6正常的情况下IE7反而令人费解。我不喜欢IE7，但容忍IE6，试想一个10年的浏览器，我还能奢求什么呢？它出生的时代满足了当时的需求，这就足够了。但IE7显然不够资格让人们容忍，幸好它不随任何一个操作系统发布，不然完全能和IE6一起称霸非标准web领域。——结论是这两者果然还是要一起放弃支持啊！

自IE9开始拥抱标准以来，标准的形势已经越来越明朗。最近各大浏览器都死命的在飙版本号——特别是Chrome，也许到明年都Chrome20了也说不定~但这样一种浪潮不正显得浏览器市场欣欣向荣么？不过开发者恐怕也要紧跟着折腾了。过几天撤了虚拟机里的XPwithIE6&7，剩下数G空间——当然我只是在为下载腾地方罢了。

为了某某.avi的磁盘空间而删掉自己的调试虚拟机因而说神马不支持IE6和IE7，是多么的有说服力的理由啊~~！

自从尝试做了swordis主题之后，对wordpress的主题也有所认识。于是决定做一个自己的主题。并且这次和上次不同，是很认真地要做完的。名字还没有想好，但是目标很明确：

• 没有图片的纯CSS主题。意味着线条和空间是首要设计元素。
• 必须过XHTML1.1以及CSS3验证。CSS3阴影和变换等，由于有前缀，所以即使使用也会暂时注释掉。
• 通过主题单元测试( Theme Unit Test )。这是一组严酷的内容兼容性检测。
• 流体布局。右边栏，因为我调查下来，比起侧边栏在左面，似乎更多人习惯在右面。
• 弹性em值。
• 兼容所有主流浏览器，包括IE6在内。

这些天从睁开眼睛开始我就在思考怎么把这个新的主题写好。主要考虑的是线条和颜色，实际上和篆刻类似，如何把自己其他方面的知识应用进去，就是这次的主要问题。

最大的挑战应该还是来自IE6的，因为这次不能写违规的hack，也不能用IE的私有属性。其实早该如此，IE6虽然仍旧苟延残喘，但是终究会被历史的洪流冲走的，我坚信这IE8成为下一个IE6的时代的来临。

前端工作类似一道工艺，相同的设计，工艺不同，价值也会天差地远。

上次试作的主题，设计用了半天，HTML化也是半天，总共才一天时间，加上才第一次做主题，自然漏洞百出。虽然大的问题暂时也没有，但是代码级别差距很大。这次截然不同，纯CSS，没有设计直接写，但是style.css我已经写了2天有余，到现在也仅仅只是有一个框架。期间数易其稿，多次改动整个布局。

现在就是主题单元测试的内容，相当周到。有多层次的页面，有混合布局、超长、超短、甚至是无标题或者无内容的文章，也有超多分类、标签的极限测试，还有何种视频嵌入，总之是应有尽有。

这次着眼于快速、准确的CSS，同时也要关注可访问性。当前使用的主题(bito)是我非常喜欢的，但也有很多缺点。这次要尽可能级联样式，并尽可能利用默认UA样式。对于这种轻量化CSS编写，CSS Rest 显得多余所以没有用。把文本字体定为14px左右(0.88em)，这样看起来才不会累吧~虽然其实主流浏览器都支持缩放，但是似乎使用这种功能的人的比例并不多。

前天粗粗看了下prototype的源码，感受颇深。这个核心框架的很多JS写法，都给了我很多启发。所以这次也打算用写JS提升下体验，尽管自己不在行。

精炼的代码，无论是C，JS之流的语言，还是CSS、html这类非语言，都应如wordpress本身所倡导的那样“代码如诗”。我很期待着自己的这个主题，期待着自己也能创造行云流水的布局，期待着自己也能哼出一段蹩脚的小诗~

关于浏览器模式，一直以来的理解是这样的：浏览器厂商出于那些老站点的向后兼容的目的，创建了两种模式。即标准模式(standards mode)和怪异模式(quirks mode)。在标准模式里，浏览器按照规范渲染页面，而在怪异模式里，浏览器以一种老式的或者是模拟老式浏览器的渲染方式表现页面。

这些并没有错，但是还不够全面和深入。当我回顾《CSS Mastery》的时候，也让我想起了很多渐渐淡忘的、并且也可能是无关紧要的其他碎片。
比如，两种模式最大的差异的例子就是IE盒模型的解释。IE如此，Opera 7也是如此。再比如，Mozilla和Safari的第三种“准标准模式(almost standards mode)”，只是在处理表格的方式上有些细微的差异，其他与标准模式无异。等等。

一直以来，确保DOCTYPE的正确也是非常重要的事。浏览器根据DOCTYPE是否存在以及是何种DOCTYPE来确定渲染方式。如果总结如表，应该是这个样子。

另外一个可能有点过时的，是Eric Meyer关于DOCTYPE switching的表格。多年之后我再去看这个链接的时候，发觉它居然还在:)
而现在，我更喜欢看QuirksMode上的资料。

实际工作中，一般都不会忘记去添加DOCTYPE，所以很多情况都只是我们无意为之。比如IE6，当DOCTYPE不是页面的第一个元素的时候，就会进入怪异模式。这导致在页面开头添加XML文件的可选声明

<?xml version="1.0" encoding="utf-8"?>

也会使页面表现出人意料。之后的IE7修复了这个bug，但却不完全。在IE7中，一个xml声明并不会再导致进入怪异模式，但是这并不表示在DOCTYPE之前加入其他东西也能不触发。比如html注释。

<?xml version="1.0" encoding="utf-8"?> 
<!-- ... and keep IE7 in quirks mode --> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

这段代码依旧触发IE7的怪异模式，而触发的原因仅仅只是一段html注释。所以在DOCTYPE前，一段html注释也会导致怪异模式下不可预料的表现。

另一个需要小心的陷阱就是BOM头。当php处理UTF文件的时候会把BOM读成字符，include之后就可能会跑到DOCTYPE前面，从而再次触发IE的怪异模式。所以保存UTF8编码的时候可以选无BOM，BOM对于UTF8的意义本来就不大。

前段时间写的HTML5，DOCTYPE简化到只剩下

<!DOCTYPE html>

对此w3cschool上的解释是这样的：HTML 4.01 中的 doctype 需要引用一个 DTD，这是因为 HTML 4.01 基于 SGML。HTML 5 不基于 SGML，也不需要引用 DTD，但是需要声明文档类型让浏览器按照它们应该的方式来运行。

事实证明，IE只要认到 <!DOCTYPE html 这串字符就会用标准模式...

也许HTML5的日子真的就这么迫近了，新的总结，那就是后话了，呵呵。
最后记录些DOCTYPE，发觉自己总是在复制他们~

HTML 4.01 Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

HTML 4.01 Transitional

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

XHTML 1.0 Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.0 Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

虽然起了一个看似很牛逼的题目，但本文可以说完全是蛋疼的人的一种消遣~通常开发人员都有自己的放松方式。写文章用不了太久，倒是图材准备了老半天。谨以此文，让我们来消遣下各个浏览器对于边框的理解方式。

参与此次测试的浏览器包括windows下的几乎全部：ie6，ie7，ie8，ie9preview，chrome，firefox，safari，opera，seamonkey。各版本皆为网上下载的最新版。并且由于这次的测试里，IE678的表现一致，firefox和seamonkey又是裙带，所以合并作IE8和firefox。下图就是这次浏览器的截图：

上面的这种排列顺序是故意的。下面的测试里就会显示出其原因，截图也都是按照这个顺序排列的。

首先看下面这张图，六种浏览器里显示了一个20X20的DIV，其边框为top:2px，其余1px。似乎没有什么不同。这是由于1px的细微让我们没有在意。(事实上这整个问题我们本来就不需要在意~)

先把问题简单化，单边2px，三边1px，并将结果放大5倍，我们能清楚的看到这种差异——opera和safari相反，ie8缺胳膊少腿，下面三个家伙一致~这里要注意到的是第二行3者在交汇处都有渐进效果。

也许我们该让这种效果变得更加明显。当仅仅加粗单边之后(10px)，IE8的怪癖显露无疑。opera和safari依旧相对。下面3个统一战线的渐进变的更加明显。

假如颠倒下会是怎样？3边加厚，结果是有些出乎意料的。opera的表现很诡异，换句话说，它顶上的那条线，在上面的例子里“优先”了只是一种巧合。IE表现的更加像opera，而不是它缺胳膊少腿的一贯形象。safari贯彻始终，并且，下面三个家伙的结果也是意料之内的。

回到最开始第一幅图的地方。用4种颜色分别画4条边。这里仍旧是放大5倍，现在就能更加清楚的看到IE8的做法。

在边框宽度都相同的情况下，每个浏览器都表现的挺好。对于边框斜角的应用我最早在《Eric Meyer on CSS 1》里看到。这种45度斜角使用上没有危险性，但是其他角度就未必是这样了，特别是用在双线的时候。
这里留意下面三个截图，FF和chrome，ie9的表现是不同的。可以看到渐进的处理方式不相同。chrome和ie9交汇处有白边，但是FF没有。

下面就是双线了，这又出了一个问题，就是ie9的双线是糊的...由于用的是4条等宽边框，其它看起来似乎都不错。

于是，换用一种糟糕点的角度呢？ie8首先不成框样，居然用空隙...感觉上非常粗糙。另外ie9糊的真水...

当我再尝试一些角度时，Opera也出问题了，它的边框显得多余很难看，简直和ie8有的一拼...

当然，本来浏览器对于线型的解释就不同，所以实线之外的，就没有什么参考价值了，这里仅做娱乐~~
dotted之后，尽显衣钵本色。

dashed又如何？同是webkit，表现却并不像刚才的dotted那么相同。ie8依旧很诡异，只有4个点，上下的线消失了...事实上，之所以这里把DIV加长到20x30，是因为，20x20，不够ie8显示这么宽的dashed线型，那4个点也会消失的~

下面就是最有趣的地方了，当DIV的尺寸变成20x40，线宽如图所示，结果，ie8和ie9是可以合体的！！！它们的合体可以组成一个完整的独一无二的solid框！一像素都不差~

当将DIV的尺寸加到的89x39的时候，ie8才完全显示出dashed框，并且此时chrome会突然变得和safari不同。

好了，也算的上是一轮浏览器的探索了。或者说消遣，再或者说无用工。因为没有结论，只有现象，而且还是无用的现象。但仍然希望这能勉强算的上是块砖头，期待高见~

国外有很多优秀的文章可以用来学习，我决定花些时间翻译。我并不知道这篇文章有没有人翻译过，原文名 10 Awful IE Bugs and Fixes，我希望能有更多人能看到这些优秀的文章。外国人很幽默，所以我也就全文翻了。

这里很多都很常见，但这不妨碍文章的好坏。

----------以下为译文----------

我列举了10个常见的IE bug和解决方法。我相信这将能够帮助你减少调试IE布局不一致时花掉的时间。

作者：kevin

简介

在处理IE方面每个人都有他们自己的故事。作为一个开发者我不得不面对大量的IE的古里古怪的问题并且有的时候你只是想用头撞墙。但是随着时间的推移，我们慢慢吃一堑长一智（有些时候那不是我们的错，是IE的错！）并且开始接受和理解IE的怪异行为。我们不得不这样因为仍然有数量可观的IE6用户。最好的做法是一开始就不断的从不同的浏览器测试你的网站。从一开始就解决布局问题要比在数千行html和css代码之后容易的多。

有很多运动在抗议IE6，支持它的是大多数web专家和看起来不怎么关心的普通用户。所以，我们现在能做什么？我们不得不继续挖掘来解决IE6的问题。但是，等一下，有一个振奋人心的消息。基于w3cschool的月度报表，IE6的用户这些年已经减少了一些。从2006年6月的60.3%到现在2009年9月的13.6%。按照这种比例，我们应该能在2010年年底的时候放弃IE6(译注：国外的情况还真是一片大好啊~。~)

好了，回到现实，我已经列出了全部我之前遇到的问题作为未来参考的列表。我相信这将能够帮助你减少调试IE布局不一致时花掉的时间。

1. IE6 幽灵文本

在我写本文之前，我遇到了这个bug。它相当的古怪和滑稽。一块不知哪来的重复的文本，被IE6显示在靠近原文本的下面。(译注：也可以参看 Explorer 6 Duplicate Characters Bug 获得bug演示)。我无法解决它，所以我搜索它，果然，这是另一个IE6的bug。

对此有许多解决方法，但是没有一个对我的例子有效(因为网站的复杂性我无法使用其中的一些方法)。所以我使用了hack。在原文本之后增加空格看起来能解决这个问题。

但是，从 Hippy Tech Blog 那里了解到，问题背后的原因是由于html注释标签。IE6不能正确的渲染它。下面是他建议的解决方案列表：

解决方法

• 使用<!—[IF !IE]>标签包围注释
• 移除注释
• 在前浮动上增加样式 {display:inline;}
• 在适当的浮动的div上使用负边距
• 在原文本增加额外的 (比如10个空格) (hacky way)

2. 相对位置和溢出隐藏

这个问题我遇到过很多次，当时我正在准备一个JQuery的教程，因为我使用了很多overflow hidden来达到我想要的布局。

问题发生在当父元素的overflow被设置成hidden并且子元素被设置成position:relative。

CSS-Trick有一个很好的例子来演示这个bug：position:relative and overflow in internet explorer

解决方法

• 为父元素增加position:relative;

3. IE的最小高度

这很简单，IE忽略min-height属性。你可以用下面的hack来修复它。感谢Dustin Diaz。

这个解决方法在IE6, Mozilla/Firefox/Gecko, Opera 7.x+, Safari1.2里都工作的很好。

解决方法

selector {  
	min-height:500px;  
	height:auto !important;  
	height:500px;  
}  

4. Bicubic图像缩放

你会喜欢这个的。IE那糟糕图像缩放让你很困扰？如果你拿IE和其他浏览器比较，IE缩小的图像看起来不如其他浏览器。

解决方法

img { -ms-interpolation-mode: bicubic; }

5. PNG透明(PNG Transparency)

我猜每个人都知道这个，但我仍把它列在这里，作为以后的参考。:)

所以如果你想要使用透明图像并且GIF不能给你想要的质量，你会需要这个对PNG的hack。你必须意识到，如果你使用一张PNG图像作为背景，你将不能设置背景的位置。

img {  
	filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(...);  
}  

6. IFrame透明背景

在firefox和safari里你应该不会遇到这个问题因为默认情况下，iframe的背景被设置为transparent，但是在IE里，却不是如此。你需要用到allowTransparency 属性并且加入下面的CSS代码来达成目的。

解决方法

/* in the iframe element */  
<iframe src="content.html" allowTransparency="true">  
</iframe>  
  
  
/* in the iframe docuement, in this case content.html */  
body {
	background-color:transparent;     
}  

7. 禁用IE默认的垂直滚动条

默认情况下，即使内容适合窗口大小，IE(译注：IE6/7)也会显示垂直滚动条。你可以使用overflow:auto，让滚动条只在你需要时出现。

解决方法

html {
	overflow: auto;  
} 

8. :hover伪类

IE只支持<a>元素的 :hover伪类。你可以使用jQuery的hover event来达到相同效果。

解决方法

/* jQuery Script */  
$('#list li').hover(  
  
	function () {  
		$(this).addClass('color');  
	},  
      
	function() {  
		$(this).removeClass('color');  
	}  
);  

/* CSS Style */  
.color {  
	background-color:#f00;    
}  

/* HTML */  
<ul id="list">  
	<li>Item 1</li>  
	<li>Item 2</li>  
	<li>Item 3</li>  
</ul>  

9. 盒模型Hack(Box Hack Model)

这是IE里最热门的bug了。基本的理解是，IE计算宽度(width)的方式不同。基于w3c标准，一个元素总宽度应该是

• 总宽度 = margin-left + border-left + padding-left + width + padding-right + border-right + margin-right

但是，IE计算宽度时没有加上填充和边框：

• 总宽度 = margin-left + width + margin-right

更多的细节，请参考这个链接：Internet Explorer和CSS盒模型详细解释

解决方法

使用w3c的标准兼容模式。IE6或者之后的版本能基于w3c的标准计算，但是你仍旧会在IE5中遇到问题。

或者你可以用CSS Hack来解决这个问题。所有标准兼容的浏览器都能读取w\\idth:180px 除了IE5。

#content {  
	padding:10px;  
	border:1px solid;  
	width:200px;  
	w\\idth:180px;  
}  

10. 双倍边距bug

如果你有一个分配有左/右边距的浮动元素，IE6会使得边距双倍化。比如，margin-left:5px 将会变成10px。你可以通过对浮动元素添加 display:inline 来解决这个问题。

解决方法

div#content {  
	float:left;  
	width:200px;  
	margin-left:10px;  
  
	/* fix the double margin error */  
	display:inline;  
}

HTML5也许真的离我们不是很遥远。今天匆匆浏览了一下3月10日版本的关于HTML5和HTML4区别的W3C的草案: http://dev.w3.org/html5/html4-differences/#changed-elements ，就更加觉得仿佛就在眼前一般。在新标签里看到了ruby的名字突然就联想到了ruby语言。虽然这个ruby和ROR没什么关系，但引起了我想要去了解的兴趣。

ruby元素是用来标记称之为 ruby 注释的。ruby 注释是用ruby字符标示在汉字等东亚字符的上方或者右方用来标示的拼音的那部分。就像小时候读课文时，标记在文字上的拼音，就是ruby字符，或者称之为ruby(rubi)。

尽管ruby是HTML5的新元素，但W3C里有关ruby的定义不仅限于草案。这里面已经有ruby注释的推荐标准，甚至有ruby的CSS3组件定义的工作草案。而在HTML5的ruby元素的定义里，可以看到关于这个标签的说明

The ruby element allows one or more spans of phrasing content to be marked with ruby annotations. Ruby annotations are short runs of text presented alongside base text, primarily used in East Asian typography as a guide for pronunciation or to include other annotations. In Japanese, this form of typography is also known as furigana.

随后我就做了相应的浏览器测试，代码如下：

<!doctype html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>Ruby Tag Test</title>
	<style>
		rt{
			font-size:12px;
		}
	</style>
  </head>
  <body>
    <p>ruby tag test</p>
	<p>
		<ruby>
			漢 <rt> かん </rt>
			字 <rt> じ　 </rt>
		</ruby>
	</p>
	<p>
		<ruby>
			漢 <rt> ㄏㄢˋ </rt>
			字 <rt> ㄗˋ　 </rt>
		</ruby>
	</p>
	<p>
		<ruby>
			汉 <rt> hàn </rt>
			字 <rt> zì  </rt>
		</ruby>
	</p>
  </body>
</html>

这段HTML在Chrome和IE9pre上都表现良好，尽管现在浏览器对于ruby标签的支持并不完善。Opera 9.64，FireFox 3.5.9，Safari 4.0.4都未能正确的显示，因为没装最新版，也不知道最新版本下会怎么样。有意思的是，IE678都支持ruby标签，虽然显示上ruby注释的字体很小，但是下面的CSS同样有效~

rt{
	font-size:12px;
}

甚至用IEtester开个IE5.5也一样可以很好的显示出ruby注释。这不禁让我感觉很怪。google后找到一份关于Internet Explorer对ruby注释的标准支持文档(MS-RUBY-Internet-Explorer-Ruby-Annotation-Standards-Support.pdf，日期03/17/2010)，里面提及了IE对于Ruby注释的支持。这包括IE7的标准模式和怪异模式、IE8的怪异模式IE7模式和IE8模式。

这下让我有点汗颜了，IE6用了这么久，居然不知道它还能支持这种东西...

其他浏览器方面，MikeSmith的博文里谈到，Chrome的开发者Roland Steiner在WebKit里添加了ruby的支持(r50495，相关的bug 28420)。这使得WebKit 的nighty和Chrome dev支持了ruby标签。

浏览器兼容更新

2010/05/19