[譯]關於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(也許還有其他的名字)始終是全屏的,那么該特性也就主要在桌面環境中使用了.

CSS

關於IE11新增了哪些CSS特性,並沒有太多的新聞,也許是因為還處於開發初期,並且IE10已經實現了不少新的CSS特性的原因.其中有一個好消息是,IE11更新了FlexBox的實現到最新版的規范草案(很有可能是最終版).Flexbox語法在IE10正式發布的前兩天發生了變化,所以導致IE10實現了一個過時的語法.我在編寫SmashingBook 3中的FlexBox一節時,就被這個問題所困擾.目前只有Opera 12.1,Chrome(帶前綴),Firefox 22實現了新版的FlexBox規范,Safari實現的仍然是舊版的規范.

接下來呢?

下面說說我希望接下來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中的這么多隱藏特性.