上周，淘宝宣布不再支持IE6以及IE7，作古的浏览器访问淘宝会看到升级浏览器的提示，当真算得上是一个时代的终结，而这个时间点距离我自己写的告别垂死的IE6与IE7足近5年之多。作为从IE6时代一路走来的前端工作者，在这样的变迁交汇点难免徒生各种感慨，还有——落寞。

怀着复杂的心理我们需要告别日以继夜为之奋斗的抑或是狂喜抑或是抓狂的岁月，努力甩开在某种程度上已经充当技术壁垒的浏览器兼容，现在开始，将是一个IE8开始的新起点。

甩开IE6和IE7，web开发者特别是前端得到了哪些解放？为此我简单罗列了一些最为常见的情况。

• inline-block，我们终于可以摆脱*display:inline;*zoom:1;的诅咒，自由使用这个常见的属性。
• box-sizing，IE8+使得border-box可以开始发挥它的威力，虽然低版本firefox可能还会遇到些问题，但我相信我们可以说服测试同学，因为已经没有IE的阻挠。
• :before :after 伪元素，终于可以自由使用这两个常用的伪元素，IE8虽然只是部分支持，但绝大多数使用场景已无问题。
• display:table-cell，表格展现可以开始用其他结构模拟了，当然还有万年话题“垂直居中”也终于不再是话题。
• 更少的浮动bug，总而言之，不是没有浮动bug，但危害已经变得非常可控。
• 部分外观可控的select组件，模拟select组件在响应式的体验很难完美，对于select有了更多的控制权的现在，还有什么理由单纯因为外观需要去模拟呢？
• :first :last 伪类，虽然很希望能从nth-child开始，但很遗憾IE8+的起点只能是:first和:last，但这真的也已经非常不错了。
• 更正常的z-index，也许我们有时还在为IE6&7的z-index的部分问题而困扰，那么看来以后我们又可以多保住几根珍贵的头发了:)

如果说IE9是微软开始拥抱标准的开始，那么IE8可以说是IE开始显得比较正常的开端。当xp系统远去，带走的是系统默认浏览器IE6，那么究竟何时，我们才能等到IE8的末路？也许还需要5年吧，虽然我觉得这次应该用不了这么久。

已经没有过多时间来叹息已经成为历史的东西了，即便那是我们曾经逝去的青春。web走向何方我们依旧需要用自己的双脚全力追赶并跟上节奏，才能见证这一切的玄妙变迁。

BGM @ Wild Side by Roberto Cacciapaglia

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，是多么的有说服力的理由啊~~！

起因是下面的这句话：

font-size: 75%; /* Resets 1em to 11px */

这是我曾经喜欢的wordpress主题 Bito 的第一句CSS。印象里还是记得默认值是16px，那么75%就是12px了。不过这只是表面问题，其实大部分人都不怎么关系字体大小的本质。

从标准看起

W3Cschools的font-size参考相当简单，只是简单的列举了属性的可取值。并且CSS2.1 Specification RC20090908里，关于font-size的定义也并不多。

大体上，font-size的值非常宽泛，即可以是关键词定义的绝对值，可以是百分比或者 em 的相对值，还可以是绝对单位px。在实际工作中，我自己都似乎快习惯于用px定义字体大小，很少使用到那些关键字或者比例，但可能这不是个好习惯。回想自己学习CSS的过程里的例项，大部分都是用em或者百分比的。

关于px

对font-size直接应用px值，这样做非常精确，而且也方便，所以我们习以为常。当对font-size赋予px值意味着浏览器将会把文本渲染成指定的像素那般高。并且通常情况是，西文字符在9px以下、中文字符在12px以下时，文字将难以辨认。使用像素单位的主要问题是两个：

1. 当把文字设定为固定px值后，IE6以下浏览器将不能对其缩放。
2. 固定尺寸后失去级联特性。

老外的眼里，第一点似乎是个大问题，因为他们把网站的可访问性和易用性看的很重，无法看清字几乎是不能容忍的。而第二点，只要不做弹性布局或者设置字体调节器之类的应用，并且针对的只是显示器，也就不是大问题。这恐怕也是导致px这么泛滥的原因。好用，简单，并且最重要的是——精确。

但是对于易用性来说，px似乎不是个好东西。
W3C Web 可访问性指南：在标记语言的属性值和样式表属性值里使用相对单位而不是绝对单位。[...]比如，在CSS里，使用 ‘em’ 或者 百分比长度 而不是使用绝对单位 ‘pt’ 或者 ‘cm’ 。

百分比的使用

百分比和em都是相对值，相对于父元素的字体大小。1em等于1个字体的大小，Chris Coyier认为em是基于大写字母 M 的宽度(除此以外，我找不到更好的参考)。使用百分比和em可以很好使得各个元素间产生级联的比例关系。

鉴于windows的浏览器，默认的字体大小是medium，即 16ppem (后面会讲到)下显示为16px。所以75%就是12px，而62.5%就是10px。

基于font-sizeのパーセント表記一覧里的百分比的零散表格，我重新组织了下面这张整表。下表仅仅作为参考，因为百分比的微弱递减或递增不会对文本产生可视化的效果(当然也有例外)，反而容易产生出混乱的级联百分比关系。

之所以选择了参考了这位日本开发者的资料是有原因的。比如，我们常常全局定义字体的相对medium(通常为16px)的62.5%，也就是10px，然后再对文档的个个其他部分定义em值。相对于10px，1.2em就是12px，1.6em就是16px，依次类推。这样的比例使用起来很直观，并且会在所有的浏览器里表现完好，当然除了IE。

IE会错误的显示字体大小(感觉上是字体框架有细微的变大)，并且仅限于中文。除非我们将比例设置成63%而不是62.5%。所以当我看到这张表中63%的时候，我觉得同是非西欧字符，这张表应该更具有参考价值。不过这些值我也没能自己去全部测试，偷懒一下～

em似乎比百分数更加直观，而且对于一个字体的宽度的把握往往也更容易。同时它们有相同的级联性，使用的时候总是要避免规则的叠加。比如定义 div{font-size:1.2em;} ，那么在div里包含div就会出问题。1.2emx1.2em的叠加会使得文字比想象中的大——但这还不要紧，如果使用的是0.8em？缩小倍率的多次叠加很快会使得文字变得无法分辨。

无论是em还是百分比，都是相对值。并且常常相对于medium。但是关于medium这类关键字，就有了更多的话题。

关键字

我对于font-size的理解一直停留在上面说的那些，直到半个月前，我读到这篇Toward a standard font size interval system。

回到之前的CSS2.1 Specification RC20090908，标准把关键字定义为这样：

下面这张图，更加直观些。但是注意第二行。同样对于English Font加上larger，IE8和FF渲染为18px，Opera、Chrome和Safari则渲染为19px。

下面的表截取自Toward a standard font size interval system里的Synoptic table，对应于windows常用的96dpi的情况。是的，96dpi，我们几乎从来不去改变这个默认的值，除非也许某个人因为高分屏字太小的折磨，而主动调大到了120dpi。

牵扯到一个很重要的概念，ppem。它指的是Pixels per em，即每个字体大小的像素数，定义了字符在屏幕上的易读性。关于更多的信息，我强烈建议阅读Toward a standard font size interval system原文。

当把xp的dpi从96调整到120， 整个系统的尺寸，包括图形和文字都被放大了。此时，如果打开IE，font-size:medium 不再是16px，而是20px。虽然我也试过Chrome和FireFox，但它们没有变化。我不明白原因，如果有人知道，麻烦请告诉我声: ）

这再次的提醒了我们，CSS不是只为显示器而设计的，而且也不是专为windows而设计的。我们有时可能需要考虑更多更多。
水平有限，文中如有错误望指正~

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

参与此次测试的浏览器包括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不同。

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