IE9下采用table布局兼容性BUG

一、问题引入

（一）上周在工作中，遇到一个很奇怪的IE9兼容性问题，给table一个高度，超出给定高度时会出现一个竖向滚动条，但是当我鼠标选中某一行元素时，滚动条会在点击的瞬间上滑到顶部，且鼠标的选中事件没有消失。

（二）问题的原因为IE9下采用Table布局的方法会存在兼容性BUG，找到了问题的原因就很好解决问题了，将页面里原有Table布局改为ul-li布局即可完美解决。

二、问题的延伸思考

（一）问题的暴露和复现

问：为何该问题我本地测试的时候没有测试出来，转测的时候也没有出现，而是直到灰度测试的时候才暴露该问题呢，难道是灰度测试环境和转测环境不同导致的？

答：否。该问题一直存在，只是没有复现而已。我在由edge模拟出的IE9环境下无法复现该问题，然而在真实的IE9下该问题出现。

问：为什么真实的IE9下可以复现该问题而模拟出的IE9环境不行呢？

答：模拟出的IE9使用的浏览器的文本模式和真实的IE9存在差异。

附：关于浏览器模式和文本模式的区别和联系，可以参考如下这篇博文https://blog.csdn.net/lnn2007/article/details/7747344

（二）问题解决后的复盘

1、IE下的兼容性问题真的很让人头疼，有没有一种一劳永逸解决兼容性问题的代码呢？查询资料后发现可以用如下这种方法解决：

< meta http-equiv = "X-UA-Compatible" content = "IE=edge,chrome=1" />来规定浏览器的渲染方式。 “chrome=1”这部分是谷歌内嵌浏览器框架GCF，这个插件可以让用户的IE浏览器外在显示不变，但用户在浏览网页时，实际上使用的是Google Chrome浏览器内核，而且支持IE6、7、8等多个版本的IE浏览器，如果客户没有安装GCF插件，则按照最高版本的IE浏览器文本模式来解析。主要用于加强代码对IE的兼容性，强制IE使用当前本地最新版标准模式渲染或者用chrome内核渲染。现在很多主流网站都有采用这种方法，如百度和CSDN等。

总结起来就是如下几点：

• X-UA-Compatible可以被用来定义浏览器的渲染方式；
• 如果存在客户端Chrome Frame并启用，那么浏览器访问页面会被Chrome内核渲染；
• 使用IE内核浏览器来访问，会渲染至该浏览器的最高版本，比如你使用IE9浏览器，那么就算在兼容模式切换至IE7，但仍会渲染成IE9的样子（但是IE7浏览器不会被渲染成IE9）。

2、性能上的提升

使用IE内核浏在64位Vista平台上分别选取IE7、IE8、安装Chrome Frame后的IE7和IE8、Chrome 3进行了Sunspider JavaScript基准测试，根据测试结果，安装Chrome Frame后的IE7速度提升了近40倍，安装该插件的IE8速度提升了10倍，两者在JavaScript处理速度上基本和Google Chrome持平。 ComputerWorld同样采用了Sunspider JavaScript基准套件进行了多次测试，同样的，安装Chrome Frame的IE8比IE8自身快9.6倍。

3、存在的弊端。

• 第一个弊端是他要求客户端安装了GCF插件后，页面才可以按照谷歌浏览器内核来渲染，如果客户没有安装GCF插件，可以采用页面底端通知的方法来通知客户安装（如下图）。但是在实际生产中这种方法不太现实，因为我们无法要求客户端来做出这种操作。
• 
• 第二个弊端是在代码调试的过程中，由于Edge 模式告诉 IE 以最高级模式来渲染文档，也就是任何 IE 版本都以当前版本所支持的最高级标准模式渲染，即使我们选择了IE9来调试，页面也会按照edge的文本模式来渲染，这也恰恰解释了为何直到灰度测试时该问题才暴露出来，可能我和测试人员都用的是模拟的IE9环境来测试的。如果在开发的过程中也遇到过浏览器兼容性问题无法复现的情况，可以排除一下是否由于这个原因导致的。