根据 Dotzler 的统计 ，IE6 的份额正在缩水，这可能是 2009 年本人听到的第一个好消息。于此同时， Gmail 的浏览器支持列表中已经将 IE6 给剔除 ，Google 官方 推荐用户使用 Firefox 或者 Chrome 可获得双倍的速度和用户体验。

那么， 似乎又回到 了 IE6 的话题。

IE6 为什么存在着？

IE6 的发布时间可以追溯到 2001 年的 Windows XP 的发布。是的，IE6 已经成为了世上最「长寿」的浏览器。而问题是，IE6 为什么能够如此顽强的存在着。抛砖引玉，本人先列举几条，欢迎补充：

操作系统的「潜规则」

Windows 系统和 IE 紧紧的捆绑，使得升级浏览器变得如履薄冰。正如我们看到的，几年来 Windows 系统的补丁也仅仅是在原有的基础上缝缝补补 -- 微软显然不愿冒这个风险。

Vista 的失败

Vista 已经变成了第二个 Windows ME 。撇开这个先不谈，用户升级浏览器的另种情况，就是操作系统的升级。Vista 商业上的失败，注定 IE6 搭载的 XP 这艘船能够续航更长的一段时间。

IE7 也不是什么好鸟

2006 年底发布的 IE7 远远的没有达到市场的预期。从当时的 IE7 发布情况看，注定 IE7 只是个过渡性的产品。

IE8 开发进展缓慢，并远被甩在了后面

「现在这个功能，我们也有了」， D2 上微软兄弟幽默的言语 也折射出一个事实，目前根本就没有用户敢用 IE8。IE6-8 三个版本并存的混乱局面，越发说明了微软的这个坑是被自己越挖越大、越挖越深了。

普通用户不在乎

是的，这是事实。普通用户而言，上网仅仅是双击某个图标，输入某个网址就可以。他不了解什么是浏览器，当然也没必要了解。对于他们而言，能够完成自己的目标才是最重要的。

国内「特殊的情况」

譬如：国内的软件几乎都是免费的，获取没有任何的成本、国内的教程几乎都是介绍怎么使用 Dreamweaver、 Firefox 在国内病毒式的推广 ，在部分「不明真相」的用户心中，俨然已经是恶意软件的代名词，等等…

「2009 年，IE6 真的会消亡吗」

那么，在接下来的 2009 年，IE6 真的会消亡吗？在本人看来，至少不会完全消亡。IE6 的完全消亡，需要我们大家共同的参与。例如，作为名前端（或者其他与浏览器打交道的兄弟），应该怎么做？

浏览器的表现不完全一致

不同的浏览器提供的功能和性能不完全一致，所以页面没必要在所有的浏览器中完全的一致。我们要让我们的同伴、用户了解，至少那 2001 年发布的浏览器所表现的性能，不可能和现代的浏览器完全一致。

对于 IE6 的优雅降级

我们可以尝试先丢下 IE6 的包袱，开始针对现代的浏览器开发，然后 优雅的降级 到老版本的浏览器。例如，我们可以高版本的 CSS 特性，然后再针对 IE6 使用单独的脚本去实现它。

继续布道

我们要让更多的人了解 IE6 是个糟糕的浏览器，并推荐他们使用更好的浏览器，譬如 Firefox、Chrome 等。

-- Split --

最后，解铃还须系铃人。2009 年微软 即将发布的 Windows7 ，从另个侧面也将推动 IE6 的灭亡。总之，09 新年伊始，是时候给那老态龙钟的 IE6 钉上棺材钉了。

周六与朋友一起，相互分享自己的新知。本人较懒，没有做过多的准备，简单的分享了下对前端这个职位的理解（ 下载 PPT ）。

其中主要讲述了前端及其职能、前端的项目开发流程等方面。这些内容 其实 圆心 已经非常详细的解说过了 ，本人也是即学即用。

前端这个职位目前在国内还是比较「新鲜」的，很多人都不了解前端具体是做什么。而可以预见的是，通过 D2 、相互分享等渠道，前端这个职位将会被越来越多的人所知。

最后，获得四个很受用的关键字

激情、执着、开放、谦逊

上述我想不仅仅是前端，也应是所有的开发人员，都值得去努力做到的。

• 原标题：The IE6 Equation
• 原作者： Jeremy Keith
• 原文连接： http://24ways.org/2008/the-ie6-equation 这个 JavaScript 天才同时开发了款名为 IE7 的脚本 。这款不可思议的脚本能够通过 JavaScript 使 Internet Explorer 5、6 的表现得像个标准兼容的浏览器。同时，这款脚本还增强了 IE 的 CSS 支持。脚本仅针对的是 Internet Explorer，因此需要使用上述的条件注释引入它

<!--[if lt IE 7]>
    <script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE7.js" 
        type="text/javascript"></script>
<![endif]-->

兼容标准的浏览器并不会运行此段脚本（对于他们而言仅仅是注释而已）。如果访问者使用的是 IE6 这糟糕的浏览器，就会额外的下载这段 Javascript 脚本。

那么问题是，什么时候应该编写额外的 IE6 样式，而什么时候应该做的仅仅是引入那段 Dean Edwards 编写的脚本呢？详细的回答这个问题，可能需要花费我和我的同事 Natalie Downe 整个上午的时间。然而回答这个问题之前，您首先需要了解并回答两个问题：「在针对 IE6 上的开发时间有多少？」以及「有多少访问者正在使用的 IE6 ？」。

让我们使用 t 表示总的开发时间、t6 表示花在 IE6 上的时间；所有的访问者数目表示为 a、 a6 则表示正在使用 IE6 的访问者。本人和那伙极具数学细胞的伙伴 Cennydd Bowles 和 Natalie 定义了下面的公式，用于量化的计算有多大的权重去使用上述 Dean Edwards 的 IE7 脚本。

p = 50 [ log ( at6 / ta6 ) + 1 ]

你可以尝试计算下属于你自己的数字。比如你花了大量的时间在 IE6 上，但只有很小部分访问者使用该浏览器，那么你可能会获得个非常高的数字。这意味着你可以使用 IE7 脚本。而反过来，如果使用较少的时间处理 IE6 的问题，或者你的大部分访问者都在使用 IE6 浏览器，那么那个 p 值会很小，这时你应该另外编写针对 IE6 的样式。

当然，实际情况是使用这个方程式显得有点自欺欺人。你可以很容易获得使用 IE6 的访问者占总访问者的比例数，但然而获得精确花费在 IE6 上的开发时间却显得相当的困难 - 或许需要当你完成了总的开发计划以后，才能得出具体所占的时间，而到那时这个方程式已经显得有点「马后炮」了。

替代上述方程式的另个方案，可以尝试下限制花费在 IE6 上的开发时间。具体是首先让你的站点与标准保持兼容，然后计划针对 IE6 上的开发时限。如果不能在这个时限内解决问题，那么替代使用 Dean Edwards 的脚本。

这一具体的占用时间可考虑和访问者使用 IE6 所占的比例进行计算。比如 20% 的访问者仍然在使用 IE6，同时你使用了 5 天开发时间完成了兼容标准的站点，那么就可以限定 1 天时间集中解决 IE6 的问题；但如果有 50% 的访问者仍然在使用着 IE6，那么你可能需要准备 2.5 天时间去解决这些问题。

所有这些针对 IE6 的处理方式的讨论没有绝对唯一的答案，同时也不可能适用于每个人。如何处理 IE6 这个棘手的问题仍然是当前的焦点之一，目前互联网上不少的 Blog、文章甚至站点都在讨论什么时候应该放弃支持 IE6。但他们没有明确的定义他们所谓的 「支持」具体是何意 。当然这不是个简单的「是」或者「非」就能回答的问题。作为替代，下面有个不同层级的支持方案：

• 将所有的 IE6 访问者踢出你的站点
• 完全遵循标准开发，并且没有任何针对 IE6 的测试
• 只使用 Dean Edwards 的脚本让 IE6 支持额外的 CSS
• 编写针对 IE6 的样式解决大部分问题（比如布局等）
• 让站点在 IE6 以及其他浏览器上看起来一摸一样

上述每个条目获得的最终结果可能是非常极端的。本人不赞成开发人员积极的抵制任何一款浏览器，也同时认为使用那些过时的浏览器的访问者获得的体验，与那些使用现代的浏览器的用户获得的不可能完全一致。真正的要点在于，IE6 被我们放在「支持」与「不支持」之间的哪个平衡点之间。

正如我认为标记语言最重要的是语义，上述的观点在 Web 开发中同样的重要。我们尝试获得更好的方式，这总要比那挂在口头的冰冷动词「支持（support）」显得更为的重要。如果你向你的访问者保证你的站点「支持」 IE6，那么你得了解更深一层的含义。相反的，如果你表明将「不支持」 IE6，那么你同样需要花点时间思考为什么需要这样做。

最后，Yahoo 的 Web 开发人员提出的 浏览器分级 概念我很认同。当然有其他的想法，我同样会有兴趣去倾听。如果我们都步调一致的发出自己的心声，那么最终我们会以更好的姿态去击败共同的对手！