关于IE11,我们所知道的以及我们所能预料到的



原文:http://generatedcontent.org/post/47216611856/ie11

---

最近,一个开发代号为Windows Blue的Windows操作系统泄漏到了互联网上,该操作系统的内置浏览器为IE11,本文将介绍一下这个泄漏版的IE11中有哪些关键的新变化和新特性.

预先声明: 本文中所讲的内容都来自互联网,我自己没有安装过这个泄漏版的IE11,虽然我目前正在帮助微软的userAgents社区做一些工作,但我没有任何关于IE11未来计划的内部消息,本文只是对网上的那些消息做了一下总结,并加入了自己的看法和预测.

一个新的身份标识

关于IE11的第一个新闻就是它有了一个新的用户代理(UA)字符串:

Mozilla/5.0 (IE 11.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko

其中有两个比较显著的变化:

1. MSIE变成了IE
2. 多了一个like Gecko字段

第一个变化很明显是想让网站上现有的UA检测失效(译者注:因为现有的检测代码都是在检测MSIE字样).UA检测是为那些老版本的IE设计的,比如它们不支持addEventListener等符合标准的特性,就得走专门的代码分支.IE这样做就是在表示,它不再需要那些专门的检测代码,它可以执行符合标准的代码了.

关于后一个变化,有报道称这是IE在伪装成Firefox,这并不完全正确.Gecko的确是Firefox的渲染引擎,这没问题,但like gecko这个字段是WebKit最先使用的,IE添加该字段的理由和WebKit当年的理由一样,那就是,网站通常不会这么问浏览器:"你想要IE私有的代码还是基于标准的代码?",而是这么问:"你是IE还是Gecko?",也就是说,即使你支持标准也没有用,你的名字必须得是Gecko.虽然目前WebKit和IE实际上比Gecko更流行,但为了兼容已有的那些老站点,必须要加上这个字段.被识别成Gecko比被识别成Webkit要好的多,因为假如被识别成Webkit,就会遇到很多WebKit私有的甚至带属性前缀的代码,尤其是在移动站点上,伪装成Gecko能好一点.

改变UA字符串并不是这个版本的IE11用来伪装自己身份的唯一手段,还有navigator.appName属性现在返回了Netscape,而不是以前的Microsoft Internet Explorer,从而与WebKit和Gecko的实现达成一致.虽然Opera/Presto没有这么干,不过它马上要切换到Blink内核了,所以所有浏览器的appName属性都将会是Netscape.

最后一个伪装方式,就是IE11现在会假装不支持document.all.如果你使用特性检测来检测浏览器是否支持document.all,它会像Firefox,WebKit,以及Opera一样,反回一个false(译者注:在非IE浏览器中,document.all是个非常特殊的属性,它是一个对象值,但它同时又是一个假值,按照JS标准,这是不可能的,查看http://www.w3help.org/zh-cn/causes/BX9002).为什么要这样做?难道特性检测不是一直提倡的做法吗?是的,但是,很多开发者们总用"特性检测"来充当"浏览器检测"(译者注:Maintainable JavaScript一书中把这种检测方式称之为"浏览器推断",是不推荐的做法),这是不对的,在Opera工作时,我曾无数次看到过下面这样的代码:

var isIE = null;
if (document.all) {
 isIE = true;
}

if (isIE) {
  // IE私有的代码,比如ActiveX,滤镜相关的
} else {
  // 符合标准的代码
}

如果document.all为真值,则你马上断定它是IE,然后执行一些毫不相关的代码(译者注:指的是与document.all这个特性毫不相关的代码,这就是浏览器推断的表现).

如果IE以后假装不支持它,就可以避免被识别出来.另外一种可能是真的完全删除掉这个属性,但这样会破坏很多网站已有的代码.伪装不支持是一个很折衷的选择,浏览器开发商喜欢这么做.

但你必须记住,所有这些变化都发生在一个泄漏版的IE11中.很有可能是IE的开发者们想试验一下,看看这些变化执行之后的修复程度是否大于其破坏程度.我们不能过早的断定这些变化都会出现在最终版本的IE11中.

所有这些变化意味着什么呢.微软实际上在告诉全世界:"IE已经成长了,它是与标准兼容的,它能够支持网站上所有符合标准的代码,我们不再希望有专门为IE准备的代码".我比较倾向于相信这一点.IE10已经向前迈了一大步,IE11也许真的能够就标准实现上和其他浏览器进行竞争.

ES6

在这个泄漏版的IE11中,发现了两个ECMAScript 6(下一代JavaScript)中的新特性:

__proto__

在ECMAScript规范中,对象的原型用[[Prototype]]内部属性来表示,我们并没有方法直接操作这个属性.ES6通过对__proto__属性进行标准化改变了这一点.IE11现在也支持了__proto__属性,和Firefox,WebKit以及Opera一起.__proto__ 属性目前是非标准的,且我认为是个非常丑的API.

WeakMap

一个WeakMap对象是一个由键值对组成的映射,其中每个键值对中的键必须是一个对象值,并且如果除了这个键以外,一旦没有其他的引用指向这个对象时,这个对象就会被垃圾回收器回收掉,当然,引用它的那个键值对也就不复存在了.正因为这种表现,所以WeakMap对象中的键是不能被遍历的.WeakMap的一个典型的使用情形就是用它来保存对DOM节点的引用,每当一个DOM节点从文档中删除之后,对应的DOM对象就会被回收掉,WeakMap对象引用它的那个键值对也会被自动删除,这样减少了对内存的占用.

支持WeakMap的浏览器有IE11,Firefox,以及Chrome(需要在chrome:flags页面中开启相关选项).

WebGL

如果说存在一个IE反对者们可以用来声称"目前的IE仍然不属于现代浏览器"的理由,那么这个理由就是IE还不支持WebGL.不过我个人认为,对于大部分web开发者来说,WebGL并不是一个最重要的特性,因为它是一个很复杂的技术,通常的网站不需要3D图形的显示.

但在某些场景下,WebGL的确是个很关键的因素,比如说游戏.Mozilla和Epic最近宣布了利用asm.js将Unreal 3引擎移植到JavaScript的消息,这也就证明了Web越来越有能力成为真正的游戏平台,以至于微软也迫不及待的实现相关技术.

在这个泄漏版的IE11中,已经能够使用WebGL了,不过使用前必须要先导入一个注册表文件才行,毕竟还在开发阶段,不能直接开放.一开始人们发现它只支持IESL着色语言(基于DirectX),而不是符合标准的GLSL(基于OpenGL),后来才发现原来注册表中的一个值能够控制浏览器在这两者之间切换.

不过我们不能高兴的太早.直到最终的IE11正式版发布之前,我们都不能确定它是否真的会成为IE11的特性.我记得当初Opera中的WebGL就是默认关闭的,因为当时让Opera访问一个带有WebGL内容的页面,就会导致操作系统的蓝屏死机(我认为这是着色器导致的).Safari目前也是默认禁用了WebGL.不过,既然微软正在实现WebGL,未来的IE11不包含它的可能性是非常小的.

网络

有证据显示,这个泄漏版的IE11已经支持了SDPY,虽然目前还不是全功能的.所以我们有理由猜测,该特性会出现在最终版本的IE11中.

SPDY是一个由Google提出的,基于HTTP的网络协议.它的主要目的是想通过降低网络延迟,压缩请求头,以及减少客户端的连接数来加速网页的加载.虽然目前SPDY还不是标准,但IETF已经用它作为了HTTP 2.0标准的基础.

SPDY目前已经被Opera,Firefox,以及Chrome支持.

DOM和JavaScript API

Mutation观察者

如果你想监视某些DOM变化,传统的做法就是去监听Mutation事件.很多人都已经知道,Mutation事件是有设计缺陷的,因为它会导致严重的性能问题.正因为这个问题,Mutation事件现已被废弃.

但是Mutation事件的功能是非常有用的,我们需要一个替代品,于是就有了DOM4中的Mutation观察者.IE11实现了这一特性,和Chrome,Safari 6,以及Firefox一起,Opera一旦切换到Blink内核,也自然会继承到这一特性.

全屏API

有时,我们希望能够隐藏掉浏览器的窗口部分,让网页占据整个屏幕来显示.最常见的使用案例应该就是在播放视频的时候了,游戏算是第二常见的案例.全屏API能够让我们实现这一需求.

看起来IE11也要实现这一规范,因为这个泄漏版的IE11中已经有了requestFullscreen方法,当然,是带有ms前缀的,剩余部分的规范应该会在接下来的版本中实现.另外,Opera也已经实现了这一规范中的所有API,且是不带前缀的.Safari,Chrome,以及Firefox中的实现是带前缀的.其中Firefox的当前实现是依据旧版规范草案的,Safari 5.1和Chrome 15–19也是(参考caniuse.com).

由于Metro IE(也许还有其他的名字)始终是全屏的,那么该特性也就主要在桌面环境中使用了.

传统 API 添加、更改和删除

许多网站查找支持传统 (HTML4) 功能的浏览器，目的是提供针对早期浏览器优化的体验。 对于支持传统功能和现行标准（如 HTML5、CSS3 等）的浏览器，这是一个问题。 如果站点在搜索现行标准支持之前检测到传统功能，则可以为支持现行标准的浏览器提供传统体验和更丰富的体验。

因此，IE11 添加、更改、删除了许多默认的传统功能：

• navigator.appName 属性现在会返回 "Netscape" 以反映 HTML5 标准和匹配其他浏览器的行为。
• navigator.product 属性现在会返回 "Gecko" 以便反映 HTML5 标准和匹配其他浏览器的行为。
• XDomainRequest 对象被 XMLHttpRequest 的 ORS 替换。
• 已添加对 __proto__ 的支持。
• 已添加 dataset 属性。

另外，为了支持现行标准指定的功能，已删除若干传统 API 功能：

删除 API 功能	替代功能
attachEvent	addEventListener
window.execScript	eval
window.doScroll	window.scrollLeft、window.scrollTop
document.all	document.getElementById
document.fileSize、img.fileSize	使用 XMLHttpRequest

CSS

关于IE11新增了哪些CSS特性,并没有太多的新闻,也许是因为还处于开发初期,并且IE10已经实现了不少新的CSS特性的原因.其中有一个好消息是,IE11更新了FlexBox的实现到最新版的规范草案(很有可能是最终版).Flexbox语法在IE10正式发布的前两天发生了变化,所以导致IE10实现了一个过时的语法.我在编写SmashingBook 3中的FlexBox一节时,就被这个问题所困扰.目前只有Opera 12.1,Chrome(带前缀),Firefox 22实现了新版的FlexBox规范,Safari实现的仍然是旧版的规范.

URL 字符编码

IE11 更改了 URL 的字符编码。 具体来说，现在使用 UTF-8 字符编码对查询字符串和 XHR 请求进行编码。

此更改会影响所有 URL，但以下除外：

• 定位名称组件（也称为“片断”）。
• 用户名和密码组件。
• file:// or ftp:// protocol links。

这些更改与其他浏览器行为匹配并简化了跨浏览器 XHR 代码。

自定义数据属性

IE11 添加了对 HTML5 自定义数据属性和 dataset 属性的支持，可以提供对它们的编程访问权限。你可以使用 data- 前缀后跟属性名称的方式来向元素分配数据属性：

HTML

复制

<div data-example-data="Some data here"></div>

要获取或设置数据属性的值，请使用此语法：

JavaScript

复制

   // to get
   var myData = element.dataset.exampleData;
   // to set
   element.dataset.exampleData = "something new";

SVG“pointer-events”属性的 HTML 支持

从 IE11 开始，也支持 pointer-events 作为 HTML 元素上的 CSS 属性，其效果如下：

值	描述
无	该元素不会触发指针输入事件（无法进行点击测试）。
其他有效的指针事件值	该元素会触发指针输入事件。

 

默认情况下将继承 pointer-events 属性，所以会影响应用该属性的元素的所有后代。

更新反映对基于标准的规范的更改

IE11 还包括用于支持基于标准的 Web 规范（已更新或仍在发展）的更新。 这其中包括与支持下列功能相关的更改：

弹性框（“Flexbox”）布局更新

使用 IE11，你可以更新站点来与最新的弹性框标准保持一致并简化跨浏览器的代码。

有关详细信息，请参阅"弹性框（“Flexbox”）布局更新"。

突变观察者

突变观察者是 IE11 中新的标准 Web 平台功能，提供了对突变事件支持的所有相同方案的快速执行直接替代，以及对属性更改事件支持的方案的替代。

有关详细信息，请参阅"突变观察者"和"将突变事件和属性更改事件迁移到突变观察者"。

指针事件

为了符合万维网联合会 (W3C) 指针事件规范的候选推荐，与 Internet Explorer 10 相比，IE11 实现已略有更改。

有关完整详细信息，请参阅"指针事件更新"。

文档模式更改

Windows Internet Explorer 8 中引入了文档模式，这些模式可以帮你实现从早期版本的浏览器支持的功能转换为现行标准和其他浏览器指定的功能。 Windows Internet Explorer 的后续版本继续使用此转换，方法是引入对行业标准所定义功能的支持的同时，引入模拟早期版本所支持功能的新文档模式。

当许多网站已更新为向其他浏览器提供更丰富的体验时，某些网站仍继续使用现有的传统功能支持向 Internet Explorer 提供传统体验，即便最新版本的浏览器支持为其他浏览器呈现的体验。

从 IE11 开始，边缘模式成为首选文档模式；它代表可供浏览器使用的现行标准的最高支持。

使用 HTML5 文档类型声明启用边缘模式：

HTML

复制

<!doctype html>

Internet Explorer 8 中引入了边缘模式并且每个后续版本中也提供了该模式。 注意，边缘模式支持的功能会限制为呈现内容的特定浏览器版本支持的功能。

从 IE11 开始，文档模式被弃用，除了临时情况外不应再使用。 请确保更新依赖于传统功能和文档模式的站点，以便反映现行标准。

如果必须针对特定文档模式，以便在重新运行站点来支持现行标准和功能时站点能够工作，则请注意，你使用的是过渡功能，以后的版本中可能不提供该功能。

如果你当前针对传统文档模式使用 x-ua-compatible 标头，则你的站点可能无法反映适用于 IE11 的最佳体验。 有关详细信息，请参阅 modern.ie。

接下来呢?

下面说说我希望接下来IE11能够实现的新特性.比如我希望能够支持CSS中的transform-style: preserve-3d,这样可以让3D效果更加完善.还有希望能支持CSS条件规则中的@supports,曾经我在摩托罗拉工作时,通过那里的Webkit团队我推进了@supports特性在Webkit中的实现,现在不光WebKit,Firefox和Opera也都已经实现.另外,如果能支持border-image也不错,要是能支持WebM等其他的视频格式就更好了,不过这一点我不报太大希望.

因为ES6中的WeakMap已经实现了,所以以后实现更多的ES6特性也不会很奇怪了,尤其是考虑到现在TypeScript也包含了不少ES6中的东西.类似的,还有微软自己的CU-RTC-Web以及设备方向等特性的实现.我想我们会在过两天旧金山举办的微软Build2013开发者大会上得知更多.

最后,感谢François Remy和Rafael Rivera发掘并公布出此泄漏版IE11中的这么多隐藏特性.