關於IE11

最近,一個開發代號爲Windows Blue的Windows操做系統泄漏到了互聯網上,該操做系統的內置瀏覽器爲IE11,本文將介紹一下這個泄漏版的IE11中有哪些關鍵的新變化和新特性.css

預先聲明: 本文中所講的內容都來自互聯網,我本身沒有安裝過這個泄漏版的IE11,雖然我目前正在幫助微軟的userAgents社區作一些工做,但我沒有任何關於IE11將來計劃的內部消息,本文只是對網上的那些消息作了一下總結,並加入了本身的見解和預測.html

一個新的身份標識

關於IE11的第一個新聞就是它有了一個新的用戶代理(UA)字符串:es6

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

其中有兩個比較顯著的變化:web

  1. MSIE變成了IE
  2. 多了一個like Gecko字段

第一個變化很明顯是想讓網站上現有的UA檢測失效(譯者注:由於現有的檢測代碼都是在檢測MSIE字樣).UA檢測是爲那些老版本的IE設計的,好比它們不支持addEventListener等符合標準的特性,就得走專門的代碼分支.IE這樣作就是在表示,它再也不須要那些專門的檢測代碼,它能夠執行符合標準的代碼了.chrome

關於後一個變化,有報道稱這是IE在假裝成Firefox,這並不徹底正確.Gecko的確是Firefox的渲染引擎,這沒問題,但like gecko這個字段是WebKit最早使用的,IE添加該字段的理由和WebKit當年的理由同樣,那就是,網站一般不會這麼問瀏覽器:"你想要IE私有的代碼仍是基於標準的代碼?",而是這麼問:"你是IE仍是Gecko?",也就是說,即便你支持標準也沒有用,你的名字必須得是Gecko.雖然目前WebKit和IE實際上比Gecko更流行,但爲了兼容已有的那些老站點,必需要加上這個字段.被識別成Gecko比被識別成Webkit要好的多,由於假如被識別成Webkit,就會遇到不少WebKit私有的甚至帶屬性前綴的代碼,尤爲是在移動站點上,假裝成Gecko能好一點.windows

改變UA字符串並非這個版本的IE11用來假裝本身身份的惟一手段,還有navigator.appName屬性如今返回了Netscape,而不是之前的Microsoft Internet Explorer,從而與WebKit和Gecko的實現達成一致.雖然Opera/Presto沒有這麼幹,不過它立刻要切換到Blink內核了,因此全部瀏覽器的appName屬性都將會是Netscape.api

最後一個假裝方式,就是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之後僞裝不支持它,就能夠避免被識別出來.另一種多是真的徹底刪除掉這個屬性,但這樣會破壞不少網站已有的代碼.假裝不支持是一個很折衷的選擇,瀏覽器開發商喜歡這麼作.app

但你必須記住,全部這些變化都發生在一個泄漏版的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實現的仍然是舊版的規範.

-------------------------------------------------------------------------------------------------------------

相關文章
相關標籤/搜索