IE6 方程式（翻译）December 10, 2008

• 原标题：The IE6 Equation
• 原作者：Jeremy Keith
• 原文连接： http://24ways.org/2008/the-ie6-equation

Web 开发人员的使命就是面对不同的浏览器。自 Web 标准运动的诞生起，有个宿命从 Netscape Navigator 4 开始就被延续着，就是那些过时的浏览器拒绝死亡。它们顽强的存在，阻碍了现代标准的发展。而今天，这个宿命降落到了 Internet Explorer 6 身上。

我保证那种掺杂着恐惧和不安的感觉，如此的熟悉。每当你下决心使用 Web 标准开发站点，使用兼容 Web 标准的浏览器，比如 Firefox、Safari 或者 Opera 的同时，到最后总是会难以避免地碰到个大问题 -- 是否兼容 IE6 。此时 IE6 上的表现会让你觉得忐忑不安，你甚至会暗自祈祷，然而那一切显得是多么的惨白。在这被宿命缠绕的浏览器上，不保证什么事情都会发生。

那么接下来应该怎么做？如果 IE6 表现的差异不大，您可能会忽视这些。在所有的浏览器下，网站的呈现效果不可能完全一致。但是如果碰到有类似布局等重大的差异，或者网站的访问者大部分使用的都是 IE6，那么你需要卷起袖子，开始着手解决这些问题。

通用的做法就是针对 IE6 再编写另外单独的样式。此引入方式可以参照 HTML 文档（译注：这不是标准的一部分）中的条件引用。比如，下面的样式只在 Internet Explorer 7 以下的版本生效：

<!--[if lt IE 7]>
    <link rel="stylesheet" href="ie6.css" type="text/css" media="screen" />
<![endif]-->

当然，你也可以在此条件注释内添加任何内容，比如在里面可以放个 script 标签（脚本）。这样可以引入针对具体浏览器的样式同时，也可以引入相应的 Javascript 脚本。

几年前微软发布了 Internet Explorer 7，具有讽刺意味的是Dean Edwards 这个 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 开发人员提出的浏览器分级概念我很认同。当然有其他的想法，我同样会有兴趣去倾听。如果我们都步调一致的发出自己的心声，那么最终我们会以更好的姿态去击败共同的对手！