浏览器模式 | navitor.userAgent | 默认文本模式 |
IE7 | MSIE 7.0 | IE7标准 |
IE8 | MSIE 8.0 && Trident/4.0 | IE8标准 |
IE9 | MSIE 9.0 && Trident/5.0 | IE9标准 |
IE9兼容性 | MSIE 7.0 && Trident/5.0 | IE7标准 |
如果仅通过 UA 中的「MSIE X.0」来判断，会得到 IE7~9 三种不同结果。
下面来看看文本模式，依然用 IE9 测试。选择不同的文本模式，documentMode 的值也不一样。
文本模式 | document.documentMode |
IE7标准 | 7 |
IE8标准 | 8 |
IE9标准 | 9 |
IE5怪异（Quirks） | 5 |
JScript 是 IE 的 JS 引擎，IE 提供了一系列 JS 接口来获取它的 JScript 信息：
函数 | 返回值 |
ScriptEngine() | JS 中固定返回「JScript」 |
ScriptEngineMajorVersion() | 大版本号 |
ScriptEngineMinorVersion() | 小版本号 |
ScriptEngineBuildVersion() | 内部版本号 |
我用这些接口测试了 IE6~10，发现 JScript 的版本号只与浏览器有关，与浏览器的浏览器模式或文档模式无关。
浏览器 | JScript 版本号 |
IE6 | 5.6.8827 |
IE7 | 5.7.22145 |
IE8 | 5.8.18702 |
IE9 | 9.0.16434 |
IE10 | 10.0.16521 |
if(ScriptEngineMinorVersion() != 0 && ScriptEngineMinorVersion < 8) { //这是 IE8- } |
实际上，IE 支持的条件编译功能中，有个表示 JScript 版本的条件编译变量，如下（完整的条件编译变量清单见这里）：
<script type="text/javascript"> /*@cc_on alert(@_jscript_version); @*/ </script> |
这个变量是「major.minor」格式的 JScript 版本号，跟使用 JS 接口获取到的版本号一致，也只取决于浏览器版本，不受浏览器模式和文本模式的影响。
看完上一节，再看我之前写的这段：文本模式决定：1）排版引擎；2）JS引擎，有明显的矛盾。难道之前的结论有误？
例如，IE8 的 JScript 版本是 5.8，但是只有在文本模式等于 IE8标准 时才可以使用 JScript5.8 的功能，其它任何文本模式都会导致页面使用 JScript5.7。
文本模式 | [,].length | [1,2,3].join(undefined) | 使用的 JScript 版本 |
IE7标准 | 2 | "1undefined2undefined3" | 5.7 |
IE8标准 | 2 | "1,2,3" | 5.8 |
IE9标准 | 1 | "1,2,3" | 9.0 |
类似的例子还有很多。大部分情况下，页面使用的 JScript 引擎版本会随着文本模式的降低而退化，页面对 JS 的支持度也随之退化。但教主 franky 提供了一个「for in顺序」的反例：
var o = {1 : '0', 0 : '1'}; for(var i in o) { console.log(i); } |
对于 IE9+ 浏览器，这行代码输出顺序始终是 0 1；对于 IE9 以下的浏览器，输出顺序都是 1 0，并不受文本模式的影响。关于这一点我没想到比较好的解释。
一些 DOM 相关的方法，如 document.querySelectorAll，在文本模式为 IE7标准、IE5怪异 时不可用；addEventListener 在文本模式为 IE8标准、IE7标准、IE5怪异 时不可用。这说明 IE 浏览器对 DOM 的支持度也会随着文本模式的降低而退化。
但是一些 BOM 方法，却跟文本模式无关。例如 IE8 开始支持的 postMessage 和 localStorage，只要浏览器是 IE8+，无论什么文本模式，这两个功能都可用。IE9+ 支持的 window.performance，在 IE9+ 浏览器上，也始终可用，跟当前的文本模式无关。
小结下：随着文本模式的降低，页面上实际使用的 JScript 引擎会退化，一些高版本支持的语言特性不再可用（如 JSON），但 for in 的顺序问题似乎不会退化；DOM 相关功能也有相应的退化；但大部分 BOM 接口却不会退化（如 localStorage）。