邊做邊學 Internet Explorer 9 相容性操作手冊

2011 年 03 月 24 日

Internet Explorer 9 相容性操作手冊

目的

《Internet Explorer 9 相容性操作手冊》是為了協助您了解 Windows Internet Explorer 9 中的變更而設計的,這些變更可能會影響您針對舊版 Windows Internet Explorer 所開發的應用程式。當中有許多變更可幫助 Internet Explorer 遵守更廣泛的業界標準,還有其他變更可提升效能與可靠性。

《Internet Explorer 9 相容性操作手冊》包含各項功能變更的相關資訊,當中會指出已過時或已移除的功能,並說明一般工具和指引。本節會隨著功能的修改,以及在您確定需要更多資訊的區域時增添新主題。

目標讀者開發人員

《Internet Explorer 9 相容性操作手冊》是針對任何有開發或維護 Internet Explorer 應用程式經驗的人所寫的。

執行階段需求

《Internet Explorer 9 相容性操作手冊》適用的應用程式包括指定 Internet Explorer 9 之前的瀏覽器版本並且可以在 Internet Explorer 9 上執行的應用程式。


Internet Explorer 9 中有所變更的功能

本節的《Windows Internet Explorer 9 相容性操作手冊》包含那些在本程式其他版本的實作方式有所變更的功能。每個案例都會說明變更的內容,並提供讓您的應用程式能夠在該項變更下運作所需採取的步驟的相關資訊。

《createElement 方法中不允許使用角括弧》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**高
**可能性:**高

描述

Windows Internet Explorer 9 不能識別 createElement 方法內的角括弧 (< >)。如果您在未設為舊版 Windows Internet Explorer 標準文件模式的 Internet Explorer 9 網頁中使用角括弧,則會發生例外狀況。例如,下面的程式碼範例將在 IE9 模式中引發例外狀況。

var elm = document.createElement("<div id='myDiv'>");

受影響的區域

如果您在 createElement 方法內使用角括弧 (< >),視發生錯誤的地方而定,網頁或網頁元件會失敗。同樣視發生的地方而定,使用者也可能受到影響。

指導方針
要順應 Internet Explorer 9 中的這項變更有兩種方法:

‧使用 setAttribute API 建立元素並分別新增屬性,如下面的程式碼範例所示。

var elm = document.createElement("div");
elm.setAttribute("id","myDiv");

‧使用 innerHTML API 在父元素內建立元素,如下面的程式碼範例所示。

var parent=document.createElement("div");
parent.innerHTML="<div id='myDiv'></div>";
var elm=parent.firstChild;

或者,您也可以將網頁設定為 Internet Explorer 9 以前的文件模式。

《OBJECT 返回內容包含於 DOM 中且依 window[name] 相互對應》

受影響的 Internet Explorer 文件模式 
Internet Explorer 9 標準

功能的影響程度 
**嚴重性:**高
**影響的可能性:**中

描述
當 OBJECT 元件具備返回內容時 (通常是 EMBED 項目),Windows Internet Explorer 9 現在會剖析該內容,並將它包含在文件物件模型 (DOM) 中,而舊版的 Internet Explorer 則不會這麼做。此行為變更可使 Internet Explorer 9 處理這類項目時更符合標準,並且提高互通性。

因此,若 OBJECT 元件具備相同的名稱屬性做為它的返回元件時,則 window[“myName”] 會將所有帶有 “myName” 名稱的所有元件集合傳回。若網頁假定 Internet Explorer 會傳回單一元件 (通常是 OBJECT 元件) 而不是元件集合,則在存取傳回值的方法和屬性時可能會導致例外狀況。

受影響的區域 
如果您對 OBJECT 元件和返回內容都使用相同的名稱屬性,並且嘗試使用 window[name] 對已具現化的外掛程式擷取其參照資訊,將可能傳回一個以上的元件,而在舊版的 Internet Explorer 只會傳回 OBJECT 元件。

舉例來說,請考慮下面的指令碼和標記:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" name="myPlugin" 
codebase="http://fpdownload.macromedia.com/get/flashplayer/current/swflash.cab">
     <param name="movie" value="myflash.swf" />
     <embed src="myflash.swf" name="myPlugin" type="application/x-shockwave-flash"
     pluginspage="http://www.adobe.com/go/getflashplayer"></embed>
</object>
plugin = window["myPlugin"]; //the OBJECT element in IE8, a collection of the OBJECT and 
EMBED elements in IE9
plugin.style.display = "none";  //Causes an exception in IE9: “SCRIPT5007: Unable to set value of the property ‘display’: object is null or undefined”

在 Internet Explorer 8 中,window[name] 只會傳回 OBJECT 元件 (因為 Internet Explorer 8 沒有將返回內容包含在 DOM 中)。

而在 Internet Explorer 9 中,EMBED 項目已包含在 DOM 中,因此 window[name] 會傳回 OBJECT 和 EMBED 元件集合。此行為可與其他瀏覽器互通,並且符合標準。

指導方針 
欲將外掛程式具現化時,可使用 document[name] 來取代 windows[name]。則當最上層的視窗被具現化後,document[name] 將會不對應到返回元件。

plugin = document["myPlugin"]; //the instantiated plugin: OBJECT element in IE, 
EMBED element in browsers which use the Netscape plugin model

其他詳細資訊:

在 Internet Explorer 9 Beta 版中,document[“myPlugin”] 會在上例中傳回 EMBED 項目,而 window[“myPlugin”] 會傳回 OBJECT 和 EMBED 元件的 HTML 集合。

不過,眾多網站上都有觀察到下列常見的編碼模式:

if(document[“myPlugin”]) {
     plugin = document[“myPlugin”]; //expected to be the object element in Internet Explorer and embed element in other browsers
}

為了提升網站相容性,Internet Explorer 9 Release Candidate 版已改善 document[name] 的行為。若是外掛程式載入成功,它將傳回已具現化的外掛程式 (在上例中,即OBJECT 元件)。這可有效地對應Internet Explorer 8 傳回的內容,同時依舊允許以符合標準的方式剖析返回內容。此行為可容上列的編碼模式在所有主要瀏覽器內互通。

window[name] 自 Internet Explorer 9 Beta 版以來還是保持不變,而且只應該在預期對應不只已具現化的項目時才使用。下表說明這些 API 在 Internet Explorer 9 中的運作方式。

window["foo"] 傳回 document["foo"] 傳回
  • a、applet、area、embed、form、frame、frameset、iframe、img 或名稱有 "foo" 的 object 元件,
  • ID 為 "foo” 的 HTML 項目
  • 顯示並且名稱或 ID 為 “foo” 的 embed 或 object 元件,
  • ebed 或無返回內容的 object 元件,也就是父系物件沒有顯示並且名稱或 ID 為 “foo” 的項目,
  • 顯示或父系沒有顯示並且名稱或 ID 為 “foo” 的 object 元件,
  • 名稱為 “foo” 的 applet、form、iframe 或 img 項目,
  • ID 為 "foo” 的 applet 項目,
  • ID 為 “foo” 並且有呈現名稱內容屬性的 img 項目

若 object 元件沒有任何子系 object 或 embed,即視為無返回內容的 object 元件。

《MIME-Handling 變更:text/css》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**高
**影響的可能性:**低

描述
網頁伺服器傳送名為 “Content-Type” 的 HTTP 回應標頭,指明傳送的是 MIME 類型的檔案。基於安全性及遵守標準的理由,樣式表應該使用 text/css MIME 類型傳遞。

  • 在 Internet Explorer 9 的標準模式中,除非使用 text/cssMIME 類型傳遞,否則將忽略 (不套用) 樣式表。
  • 在所有文件模式中,如果樣式表是使用 X-Content-Type-Options:nosniff 標頭傳遞,而不是使用 text/cssMIME 類型傳遞,將忽略該樣式表。
  • 在所有文件模式(以及舊版瀏覽器中),除非樣式表是使用 text/cssMIME 類型傳遞,否則將忽略從跨原始來源內容 (例如,example.com 使用 Microsoft.com 的樣式表) 傳遞的樣式表。

受影響的區域

如果樣式表因為不正確的 MIME 類型而被忽略,您的網站可能無法如預期呈現。文字、影像或其他功能可能會缺乏所需的樣式。

如果樣式表因為沒有正確的 MIME 類型而被忽略,將會在 IE9 F12 開發者工具主控台中記錄一則通知。

如果瀏覽器套用了使用不正確 MIME 類型的樣式表中的樣式,簡單的 test case(http://the-dees.webs.com/iepp1/13-css-media-type.html) 會顯示紅色文字,如果正確忽略無效的樣式表,則會以綠色呈現該文字。

指導方針

確定所有樣式表皆使用適當的 HTTP 回應標頭:Content-Type:text/css

如果您發現任何傳送不當 MIME 類型而且在 Internet Explorer 表現行為不正確的網站,請在 Connect 上提報錯誤

《MIME-Handling 變更:text/plain》

受影響的 Internet Explorer 文件模式
所有文件模式

受影響的 Internet Explorer 瀏覽器模式
IE9 瀏覽器模式 (所有文件模式)

**功能的影響程度
嚴重性:**高
**影響的可能性:**低

描述

在 Internet Explorer 9 的瀏覽器模式中,使用 text/plain MIME 類型傳遞的文件,不會將 MIME 視為為另一種類型。文件只會呈現或下載為純文字。

受影響的區域

如果 IE9 遇到使用text/plain content-type傳遞的HTML文件,除非網站是在相容性檢視中呈現,否則文件將呈現為純文字。

這對 Web 開發人員來說很有用,因為如此更方便共用 HTML 原始碼片段。就安全性的觀點來看這也是有益的變更,因為 IE9 在使用 text/plain 內容類型傳遞的檔案內就比較不容易受到指令碼插入的攻擊。

指導方針

  • 使用內容類型 text/plain 以確保在 IE9 中呈現純文字
  • 設定您的伺服器,對伺服器要傳遞的文件皆傳送適當的Content-Type 標頭;例如,如果您的伺服器提供 PDF 下載檔案,請確定這些檔案都是使用 application/pdfMIME 類型傳遞

如果您發現任何傳送不當 MIME 類型而且在 Internet Explorer 表現行為不正確的網站,請在 Connect 上提報錯誤。

《MIME-Handling 變更:X-Content-Type-Options:nosniff》

受影響的 Internet Explorer 文件模式
全部

**功能的影響程度
嚴重性:**高
**影響的可能性:**低

描述

如果伺服器傳送回應標頭 X-Content-Type-Options:nosniff,SCRIPT 和 STYLESHEET 項目將拒絕內含不正確 MIME 類型的回應,此為安全性功能,有助於防範以 MIME 類型混淆為基礎的攻擊。

受影響的區域

這項變更會影響瀏覽器在伺服器於其回應上傳送 X-Content-Type-Options:nosniff 標頭時的行為。

如果 STYLESHEET 參照所接收的回應上有收到 nosniff 指示詞,除非 MIME 類型符合 text/css,否則 Internet Explorer 將不會載入 “stylesheet” 檔案。

如果由 SCRIPT 參照擷取的回應上有收到 nosniff 指示詞,除非 MIME 類型符合下列其中一個值,否則 Internet Explorer 將不會載入 “script” 檔案:

  • application/ecmascript
  • application/javascript
  • application/x-javascript
  • text/ecmascript
  • text/javascript
  • text/jscript
  • text/x-javascript
  • text/vbs
  • text/vbscript

當這類內容遭到封鎖時,F12 開發者工具會顯示下列訊息:

SEC7112:因為 MIME 類型不符 script.asp,所以從
http://www.debugtheweb.com/test/mime/textplainnosniff.asp 封鎖指令碼

指導方針

確定收到含有 nosniff 指示詞的任何回應內,所具的 MIME 類型符合上列其中一個值。

如果您發現任何傳送不當 MIME 類型而且在 Internet Explorer 表現行為不正確的網站,請在 Connect 上提報錯誤。

《IE9 標準模式不支援 arguments.caller 屬性》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**影響的可能性:**中

描述

arguments.caller 屬性在 Internet Explorer 9 的 IE9 標準模式中沒有受到支援。

受影響的區域

當建立引數物件時,Internet Explorer 8 和 Quirks 中的所有模式,以及 Internet Explorer 9 的 IE7 標準和 IE8 標準模式,都會建立一個名為 “caller” 的屬性。此 caller 屬性會儲存對呼叫它的函式的 argument 物件參照。

在下例中,IE8 和 Quirks 中的所有文件模式,以及 IE9 的 Internet Explorer 7 標準和 Internet Explorer 8 標準文件模式會傳回 “1”。Internet Explorer 9 標準模式會發出「物件為 null 或未經定義」的指令碼錯誤。

function alertCallerLength() {
    alert(arguments.caller.length);
}

function callingFunction() {
    alertCallerLength();
}
callingFunction(1);

《二進位元素行為的自動繫結功能無法使用》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**可能性:**低

描述

Windows Internet Explorer 8 並不含使 Windows Internet Explorer 與其他瀏覽器更一致的自動繫結功能。例如,下面的程式碼會在 Internet Explorer 8 中啟動 SVG 外掛程式 (如果該外掛程式有註冊 SVG 命名空間的話)。

<html>
 <head>
  <title>SVG embedded inline in XHTML</title>
 </head>
 <body>
  <svg width="600" height="300" xmlns="http://www.w3.org/2000/svg">
   <linearGradient id="gradient">
    <stop style="stop-color:yellow" offset="0%" />
    <stop style="stop-color:green" offset="100%" />
   </linearGradient>
   <rect x="0" y="0" width="100" height="100" style="fill:url(#gradient)" />
   <circle cx="50" cy="50" r="30" style="fill:url(#gradient)" />
   <circle cx="150" cy="100" r="50" />
  </svg>
 </body>
</html>

但是在 IE9 模式中,這段程式碼範例是使用 Windows Internet Explorer 9 中的原生 SVG 處理功能。

受影響的區域

移除這項功能只會影響您針對 Internet Explorer 8 建立的網頁。使用者會看到一般的元素而不是特定控制項。

指導方針

針對 Internet Explorer 9 建立網頁時,您必須手動起始繫結控制項,如下面的程式碼範例所示。

<html xmlns:svg>
 <head>
  <title>SVG embedded inline in XHTML</title>
  <!-- The following is the "hookup code"  that Internet Explorer requires. –->
  <object id="AdobeSVG" classid="clsid:78156a80-c6a1-4bbf-8e6a-3cd390eeb4e2">
  </object>
  <?import namespace="svg" implementation="#AdobeSVG"?>
 </head>
 <body>
  <svg:svg width="600" height="300">
   <svg:linearGradient id="gradient">
    <svg:stop style="stop-color:yellow" offset="0%" />
    <svg:stop style="stop-color:green" offset="100%" />
   </svg:linearGradient>
   <svg:rect x="0" y="0" width="100" height="100" style="fill:url(#gradient)" />
   <svg:circle cx="50" cy="50" r="30" style="fill:url(#gradient)" />
   <svg:circle cx="150" cy="100" r="50" />
  </svg:svg>
 </body>
</html>

不過,若是您將網頁設定在 IE8 模式中執行,前述程式碼語法即可正確執行。

《使用不含 ".call" 或 ".bind" 的函式指標呼叫方法》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**影響的可能性:**中

描述

舊版 Internet Explorer 支援快取方法的指標,然後使用該快取的指標來呼叫方法。為了提高與其他瀏覽器的互通性,Internet Explorer 9 中已移除這項支援功能。

在鎖定舊版 IE 的網頁上為了使 JavaScript 程式碼更加精簡,常見的做法是將常用的方法儲存為變數,然後將該變數替代該方法來使用:

var d = document.writeln;
d("<script language=VBScript>");

在 IE9 中,需要有物件才能呼叫方法。"window" 物件預設是在全域範圍內提供 (譬如在上例中)。但是"window" 物件並沒有 "writeln" 的方法,因此會報告 JavaScript「呼叫物件無效」的錯誤訊息。

受影響的區域

指令碼錯誤:「呼叫物件無效」

指引

就跟其他所有瀏覽器一樣,您現在也必須指定方法呼叫的目標。因此雖然這段程式碼在 IE8 及之前的版本中可行:

var d = document.writeln;
d("<script language=VBScript>");

它現在在 IE9 中會失敗,就跟在其他所有瀏覽器中失敗一樣。簡單解決此問題的方法是使用"call" 方法 (所有函式的屬性) 明確提供適當的呼叫物件:

d.call(document, "<script language=VBScript>");

長期解決此問題的方法是使用 JavaScript 的 "bind" API,建立隱含的呼叫物件與方法的關聯。方法如下 (同樣是取自上例):

var d = document.writeln.bind(document);
d("<script language=VBScript>"); // Now this is OK.

《內容屬性和 DOM Expando 不再相連接》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**影響的可能性:**中

描述

在舊版 Internet Explorer 中,內容屬性是做為 DOM expando 呈現在 JavaScript 物件上。在 Internet Explorer 9 中,已斷絕內容屬性與 DOM expando 之間此一連結,以提高 IE 與其他瀏覽器的互通性。

內容屬性是在 HTML 原始碼中指定的屬性,例如 <element attribute1="value" attribute2="value">。許多內容屬性都是 HTML 預先定義的一部分;HTML 也支援其他使用者定義的內容屬性。

DOM expando是 JavaScript 中可從物件擷取的值,例如document.all["myelement"].domExpando。大多數物件都有一組預先定義的屬性,通常是以其同名的內容屬性表示。JavaScript 也支援其他使用者定義的屬性。

在下例中,'id' 和 'class' 都是 HTML 中預先定義的內容屬性,而 'myAttr' 則是使用者定義的內容屬性:

<div id="myElement" class="b" myAttr="custom"></div>

在下面的指令碼範例中,'id' 和 'className' 都是預先定義的屬性:

var div = document.getElementById("myElement");
var divId = div.id; // Gets the value of the id content attribute
var divClass = div.className; // Gets the value of the class content attribute

在 IE8 和之前的版本 (包括 IE9 中的 IE8 文件模式和舊版模式) 中,'myAttr' 內容屬性的存在等於暗示 'myAttr' DOM expando 的存在:

var divExpando = div.myAttr; // divExpando would get the value "custom" in IE8

IE9 中的突破性變更是使用者定義的內容屬性將不再暗指 DOM expando。

var divExpando = div.myAttr; // divExpando would get an undefined value

受影響的區域

這個問題很明顯是指令碼錯誤,但是在 JavaScript 程式中幾乎無法直接在失敗點看出此問題。而往往是當 [假定自擷取] 自 DOM expando 的值用在程式碼的另一個部分時才會看到失敗的情形。

指引

若要修正此問題,請使用 'getAttribute' API 擷取使用者定義的內容屬性值。建議對所有 IE 版本採取此因應措施,與舊版 IE 相比,對新版的 IE 無需特殊大小寫。

例如 (根據上個範例):

不要使用:

var divExpando = div.myAttr;

而改用:

var divExpando = div.getAttribute("myAttr");

《若從 DOM 樹狀目錄移除 iFrame 則API 無法使用》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**影響的可能性:**低

描述

在已從 DOM 樹狀目錄移除的 iFrame 項目的視窗上無法呼叫包括 JavaScript 和 DOM API 在內的內建 API。以下的定義將有助於了解此主題。

**暫時性 iFrame:**已剖析或暫時建立、新增然後從 DOM 樹狀目錄移除,而且沒有重複使用的 iFrame 即稱為「暫時性」iFrame。

**孤立視窗:**當暫時性 iFrame 從 DOM 樹狀目錄中移除時,其視窗在關閉之前都被視為「孤立」(仍處於存留狀態,但無法直接連線)。

受影響的區域

當 iFrame 項目從 DOM 樹狀目錄移除時,其孤立視窗物件也會關閉。關閉的視窗將不允許呼叫任何內建 API,包括 JavaScript 和 DOM API 在內。這是自 IE8 行為的變更,其中暫時性 iFrame 的 window 物件不關閉也會保持孤立狀態。此行為變更只存在於 IE9 模式。舊版模式的表現方式跟在 IE8 中一樣。

指導方針

在舊版 IE (包括舊版 IE9 文件模式) 中,當 iFrame 從 DOM 樹狀目錄移除時,孤立視窗的記憶體只有在瀏覽頁面時才會重新宣告。在頁面瀏覽之前,孤立視窗的記憶體會持續存在,而不會被回收。如果網站使用多個暫時性 iFrame 下載和/或執行內容,並且其間沒有瀏覽頁面,在這類罕見的情況下,每個孤立視窗的記憶體使用量會逐漸累積起來,直到對使用者在頁面瀏覽上產生使用體驗的負面影響。

為了解決這個效能問題,IE9 標準模式現在會在離開 DOM 樹狀目錄之後 (並於目前指令碼完成執行之後),立即關閉孤立視窗。如此就可對關閉的視窗進行記憶體回收。暫時性 iFrame 也會自孤立視窗中斷連線,而且無法再直接存取 (例如,暫時性 iFrame 的 contentWindow 屬性將傳回 null)。

如果對現在已關閉的孤立視窗中的物件存有既存的參照,則嘗試在該些物件上使用內建 API 將擲回例外狀況。「無法執行已被釋放的指令碼。」

我們建議在視窗進入其孤立狀態之前,取用或將孤立視窗中所需的任何物件複製到外面。

緩和措施

如果您的應用程式使用的程式設計模式受到此問題的波及,您應該考慮不要將 iFrame 由該頁面移除。

另一個解決方法是在將 Iframe 從文件移除之前 (也就是在 iFrame 的視窗變成孤立狀態之前),確定暫時性 IFrame 內的物件上的所有依存性都已解析完畢。

《動態 VML 模式可能無法運作》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**影響的可能性:**低

描述

若要在 Internet Explorer 9 標準模式中支援動態 VML,必須在指派任何 VML 屬性之前,將 VML 行為附加到元件中。如果操作順序相反,則 VML 引擎便無法由 DOM 取值,亦或 VML 可能無法正確呈現。在下例中,VML 順利地以靜態的方式載入:

<style>oval {behavior: url(#default#VML);position:absolute}</style>
<body>
 <oval style="left:0;top:0;width:100px;height:50px" fillcolor="blue" stroked="f"/>
</body>

假如在加入樣式表之前存取 'oval' 項目並且該物件上有設定 'fillcolor' 屬性,就可能發生問題。在這種情況下,VML 將無法擷取 fillcolor 值,而且可能無法正確呈現。

此問題常見於使用 VML 呈現進階字型的舊版 Cufon.js 程式庫 (或是 Canvas 標記,如果有的話)。

受影響的區域

網頁上遺漏文字,文字上下顛倒,遺漏 VML 圖形

指引

如果頁面是使用 Cufon 程式庫,請將該程式庫更新至與 IE9 相容的最新版本。

《JavaScript 屬性列舉在 Internet Explorer 9 中不同》

受影響的 Internet Explorer 文件模式
IE9 標準 | IE8 標準 | IE7 標準 | Quirks

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**影響的可能性:**低

描述

由於 Internet Explorer 9 的 JavaScript 物件模型中所做的變更,JavaScript 屬性的列舉方式跟在 Internet Explorer 8 中可能不太一樣。

受影響的區域

當在任何文件模式內使用 for… 陳述式時,屬性列舉的順序可能與 Internet Explorer 8 傳回的順序不同。例如,數值屬性現在是列舉在非數值屬性之前。下例說明 Internet Explorer 8 與 Internet Explorer 9 之間的列舉順序的差異:

var obj = {first : "prop1", second: "prop2", 3: "prop3"};
var s = "";
for (var key in obj) {
    s += key + ": " + obj[key] + " ";
}
document.write (s);

在 Internet Explorer 8 和 Internet Explorer 9 中執行此範例會輸出下列結果:

Internet Explorer 8 的所有模式:

first: prop1 second: prop2 3: prop3

Internet Explorer 9 的所有模式:

3: prop3 first: prop1 second: prop2

Internet Explorer 8 並不包含與原型物件的內建屬性同名的屬性列舉。Internet Explorer 9 中的所有文件模式則會在列舉中包含這些屬性。下列說明此項差異:

var obj = { first: "prop1", toString : "Hello" }
var s = "";
for (var key in obj) {
    s += key + ": " + obj[key] + " ";
}
document.write (s);

在 Internet Explorer 8 和 Internet Explorer 9 中執行此範例會輸出下列結果:

Internet Explorer 8的所有模式:

first: prop1

Internet Explorer 9的所有模式:

first: prop1 toString: Hello

《數學精確度在 Internet Explorer 9 中不同》

受影響的 Internet Explorer 文件模式
IE9 標準 | IE8 標準 | IE7 標準 | Quirks

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**影響的可能性:**低

描述

數學精確度在某些邊界情況下與 Internet Explorer 8 不同。

受影響的區域

Chakra 引擎使用 Streaming SIMD Extensions 2 (SSE2) (如果平台有支援的話),達成更快速的數學運算,但是也會在精確度方面產生有別於 Internet Explorer 8 的 JScript 引擎的差異。下列說明了這項差異:

function test() {
    var x = 6.28318530717958620000;
    var val = Math.sin(x);
    document.write(Math.abs(val)) 
}
test();

在 Internet Explorer 8 的所有模式中,這會輸出 “2.4492127076447545e-16”。當平台支援 SSE2 時,在 Internet Explorer 9 的所有模式中,這會輸出 “2.4492935982947064e-16”。

《泰文及東亞文字和調整字型大小》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**低
**影響的可能性:**高

描述

泰文和東亞文字在 IE9 看起來可能比在 IE8 和舊版本中還要小。在 IE8 中,泰文和東亞文字可在下列情況下以大於指定大小的字型呈現:

  • 指定字型大小為 9pt 或更小
  • 指定的字型系列不支援泰文或東亞字元,例如 Arial

因此,8pt Arial 的泰文段落會使用 [網際網路選項 – 字型] 中指定的後援字型來呈現,而後者之後會配合 Ariel 公制放大調整。因此,如果網頁作者要求使用 8pt 的字型大小,則實際尺寸會更大。

在 IE9 中,則始終採用指定的字型大小。因此,由於後援字型不會再放大調整,文字可能看起來可能會比較小。

受影響的區域

與字型大小相關的泰文及東亞內容。

指導方針

請盡可能確定 CSS font-family 屬性的第一個值支援您的語言。

比方說,使用 MS Pgothic 來取代 Arial。使用 Mincho 來取代 Times New Roman。使用 Meiryo 來取代 Verdana。您可以使用 [網際網路選項 – 字型] 對話方塊來檢查 IE 所使用的預設後援對應。

這可確保您的文字在 IE 的所有版本和模式中皆使用指定的字型大小呈現。

《預設使用者代理(UA) 字串已變更》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**低
**可能性:**高

描述

使用者代理程式 (UA) 字串在 Windows Internet Explorer 9 中有幾方面都有所變更。

縮短的使用者代理程式字串

根據預設,Internet Explorer 9 會傳送簡短的新 UA 字串來提升整體效能、交互操作性和相容性。Internet Explorer 9 並不會傳送安裝在電腦上的其他軟體所新增的 UA 字串,例如 .NET Framework 和其他許多程式。

Internet Explorer 8的UA字串有四項主要的變更:

  • 應用程式版本已從「Mozilla/4.0」遞增為「Mozilla/5.0」,以配合其他瀏覽器,而使 Internet Explorer 9 成為可互通的瀏覽器。
  • 版本語彙基元已從「MSIE 8.0」遞增為「MSIE 9.0」。
  • Trident 語彙基元已從「Trident/4.0」遞增為「Trident/5.0」。
  • Internet Explorer 9 會傳送下面的簡短 UA 字串,而不包含其他安裝在電腦上的其他軟體新增的內容。
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

由於先前冗長、延伸的 UA 字串會導致相容性問題,Internet Explorer 9 因此不加任何 Pre-Platform 和Post-platform 登錄值語彙基元傳送稍早所示的簡短 UA 字串。

應用程式和平台可像在前版 Windows Internet Explorer 中一樣繼續透過 Pre-Platform 和 Post-Platform 登錄機碼新增內容到 UA 字串。Internet Explorer 9 不會變更現有的登錄值。

您的網站仍舊可以使用 Pre-Platform 和 Post-Platform 語彙基元透過 navigator.userAgent 屬性取得延伸的 UA 字串。

相容性檢視中的 UA 字串

跟 Windows Internet Explorer 8 類似,Internet Explorer 9 相容性檢視也對應到 Windows Internet Explorer 7 標準模式。相容性檢視中的 Internet Explorer 9 UA 字串採用下列格式。

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0)

在相容性檢視中,Internet Explorer 9 會透過應用程式版本號碼 (例如「Mozilla/4.0」) 和版本語彙基元 (例如「MSIE 7.0」) 將自己報告為 Windows Internet Explorer 7 以達相容性。遞增的 Trident 語彙基元 (從「Trident/4.0」到「Trident/5.0」) 讓網站得以區別在相容性檢視下執行的 Internet Explorer 9 與在相容性檢視下執行的 Internet Explorer 8。

指導方針

透過登錄來檢查和變更 UA 字串,藉此測試您的網站如何回應 Internet Explorer 9 UA 字串。如果您的網站還沒有以 Internet Explorer 相容的內容回應,請進行更新以便識別 Internet Explorer 9 並因應未來的發展。

《間接 'eval' 函式呼叫在 Internet Explorer 9 中的表現方式不同》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**低
**影響的可能性:**低

描述

在函式內間接呼叫 eval 方法 (也就是採用明確使用它的名稱以外的方法),會在 Internet Explorer 9 中產生與 Internet Explorer 8 不同的結果。

受影響的區域

在 Internet Explorer 8 和 Quirks 的所有模式中,以及 Internet Explorer 9 的 IE 7 標準和 IE8 標準模式中,傳遞給間接 eval 的字串是在本機函式範圍內進行評估。在 Internet Explorer 9 的 IE9 標準模式中,則是根據 ECMAScript 標準 (第 5 版) 在全域範圍內進行評估。

在下例中,是透過將 eval 函式指派給變數並且把該變數當作 eval 來呼叫的方式,間接呼叫 eval 函式。

function test() {
   var dateFn = "Date(1971,3,8)";
   var myDate;
   var indirectEval = eval;
   indirectEval("myDate = new " + dateFn + ";");
   document.write(myDate);
}
test();

本範例在 Internet Explorer 8 和 Quirks 的所有模式中,以及 Internet Explorer 9 的 IE 7 標準和 IE8 標準模式中將傳回 “Thu Apr 8 00:00:00 PDT 1971”。而在 Internet Explorer 9 的 IE9 標準模式中,這會輸出 “undefined”。

《Internet Explorer 9 處理含大型索引的陣列項目的方式不一樣》

受影響的 Internet Explorer 文件模式
IE9 標準 | IE8 標準 | IE7 標準 | Quirks

**功能的影響程度
嚴重性:**低
**影響的可能性:**低

描述

含大型索引的陣列項目的處理方式與 Internet Explorer 8 不同。

受影響的區域

在陣列的 length 屬性的初始值大於 2E+31-1 (亦即 2147483647) 的情況下,Internet Explorer 8 並不符合 ECMAScript (第 3 版) 規格。當使用大於 2147483647 的索引建立陣列項目時,新建立項目的索引將會是負整數。

Internet Explorer 9 會正確處理使用介於 2E+31-1 和 2E+32-2 指數之間的陣列項目。Internet Explorer 9 的任何文件模式中並未複寫 Internet Explorer 8 行為。

當項目推送到長度為 2E+31-1 的陣列時,即可觀察到此現象。

下例在 Internet Explorer 8 輸出 “true”,但是在 Internet Explorer 9 輸出 “false”。

function test() {
    var arr = new Array();      
    arr[2147483650] = 10000;
    arr.push(10);   
    document.write(arr["-2147483645"] == 10);
}
test();

《重疊元素會被複製》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**低
**可能性:**低

描述

在 Internet Explorer 9 中,重疊的格式化元素是會被複製的,其用意是為了減低在 DOM (Document Object Model) 中語意模糊的情況。

受影響的區域

一般來說,網站有沒有這項功能看起來都一樣。

不過,若是您對標記中的重疊元素執行 DOM 操作,該動作在 Internet Explorer 9 中的運作方式可能不一樣。舉例來說,假如您對重疊元件進行像是 firstChildnextSibling 這類的 DOM 呼叫,這些呼叫可能不會以相同的方式運作。

指導方針

使用 Internet Explorer開發工具來測試您的程式碼,以找出並修正所有的重疊元素。

《有些行為連接方法在 XML 無法運作》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**可能性:**低

描述

用於連接行為的標記式表單在 Windows Internet Explorer 9 模式中可運作,但在 xml 模式中則無法運作。行為可在網頁的最上層指定,如下面的程式碼範例所示。

<html xmlns:myNamespace>
    <?import namespace="myNamespace" implementation = "my.htc">
    …
    <myNamespace:calendar/>

受影響的區域

此問題只影響新內容。

指導方針

請不要使用 HTML 標記,而透過 behavior 屬性改以階層式樣式表 (CSS) 註冊,如下面的程式碼範例所示。

<style>
.calendar {
-ms-behavior: url(my.htc);
}
</style>
…
<div class="calendar"></div>

您可以透過 class 屬性以外的元素使用 CSS 註冊。

《styleSheet.title 在 IE9 模式中為唯讀》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**低
**影響的可能性:**低

描述

在 IE8 模式及舊版中,您可以變更 styleSheet Object 的標題值。而在 IE9 模式中,將會忽略寫入命令,並將保留原始值。

受影響的區域

這對頁面的影響將因頁面變更 styleSheet 標題的理由而異。

指導方針

如果您必須變更 styleSheet Object 標題,可以藉由變更 link 項目上的 title 屬性或包含 styleSheet 的 style 項目來變更。

《表格物件模型現在跟其他瀏覽器更一致》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**可能性:**中

描述

為了改善 Windows Internet Explorer 與其他瀏覽器之間的一致性,IE9 標準模式包含了下面對表格物件模型的變更:

  • 額外的 theadtfoot 元素不會出現在 tBodies 集合中。
  • 資料列集合有不同的順序。它會先包含 thead 元素中所有的資料列,接著是未含在 tfoot 元素中的其餘所有資料列,再來是 tfoot 元素中任何資料列,無論其在文件中的順序為何。
  • 對資料列的呼叫會傳回表格內所有階層的所有資料列,包括表格的直屬資料列子系。
  • getElementsByTagNameHtmlElement.children 方法不會傳回註解節點。

受影響的區域

如果您在應用程式中考慮這些變更,應用程式可能會遇到問題輕微、無法載入網頁或建立非預期內容等指令碼錯誤。

指導方針

如果您的程式碼可用於其他瀏覽器,應該可用於 Windows Internet Explorer 9。

如果您還沒在其他流覽器內測試過您的程式碼,可能需要更新程式碼才能用於 IE9 標準模式。使用 Internet Explorer 開發者工具找出並修正問題來測試您的程式碼。

或者,您也可以強制 Internet Explorer 使用 IE8,並使用與 Windows Internet Explorer 8 相同的行為。

《文字版面配置使用自然度量法》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**不一 (視網頁使用該功能的方式而定)
**可能性:**中

描述

對於 IE9 標準模式中的文字版面配置,Windows Internet Explorer 9 使用自然度量法,而非其他 Microsoft Windows 瀏覽器使用的圖形裝置介面 (GDI) 度量法。GDI 度量法會將文字與像素界限對齊,而自然度量法則會使用內部像素的間距來呈現更準確且更容易閱讀的文字。

Windows Internet Explorer 的其他文件模式則繼續使用 GDI 度量法。

受影響的區域

針對舊版文件模式所寫的頁面版面配置在 Internet Explorer 9 中可能無法正確顯示。最常見的錯誤是未預期的文字換行,這可能會遮蓋位於換行文字下方的元素。當文字方塊沒有多餘的水平空間或是當文字方塊的大小與頁面上的其他元素 (例如圖形) 相連時,很可能會發生此錯誤。

指導方針

請勿假設特定字型的大小在不同瀏覽器間或是在相同瀏覽器內都會依相容的方式呈現,因為使用者可能會選擇顯示較大的字型 (例如,125%)。

建議事項

利用下列設計準則,確定您的網頁顯示文字版面配置的方式一致:

  • 將文字方塊的大小設定為特定的像素數。
  • 在文字方塊中包含額外的空間,避免空間過緊。
  • 使用非靜態大小的文字方塊。
  • 在與其他頁面元素相依的繫結區域中包含額外空間。
  • 如果您允許使用者變更頁面字型大小,確定您的頁面可以順應文字換行。
  • 在所有常見的瀏覽器內測試您的頁面。如果您發現文字換行的問題,請調整頁面,確定頁面適當地呈現文字。
  • 如果您針對舊版模式設計網頁,並且不想將它更新為使用自然度量法,請設定讓該頁面即使使用者是在 Internet Explorer 9 中檢視,也是在該模式中顯示。

不建議事項

避免對文字版面配置採用下列設計:

  • 指望字型大小在不同瀏覽器間以相同的方式呈現。
  • 使用靜態大小的文字方塊。

《文件物件模型中會保留空白字元》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**低
**可能性:**低

描述
您新增的任何空白字元都會存留在文件物件模型 (DOM) 中。請考量下面的程式碼範例會如何在 Windows Internet Explorer 9 與Windows Internet Explorer 8 中顯示。

<div>
   Text </div>

Internet Explorer 9:

div
              |->"\n   Text "

Internet Explorer 8:

div
              |->"Text"

受影響的區域
如果您想要 Internet Explorer 8 的行為,請使用 Element Traversal API (例如, firstElementChild)。


Internet Explorer 9 中已過時的功能

本節的《Windows Internet Explorer 9 相容性操作手冊》包含 Microsoft 已過時的功能。Microsoft 會指出「已過時」的功能,以警惕開發人員不要在未來使用該些功能,以便淘汰這些功能:

  • 如果 Internet Explorer 9 中有加入新標準支援,則 MSDN 上相關聯的功能文件會標示為「已過時」,並且會包含替代標準的連結。
  • 如果某功能是 Web 平台功能,所有文件模式都會一直支援該功能到只有極少數的網站使用它為止。

每種情況都會指出取代該功能的 W3C 標準。

《部分 DOM 事件已過時》

受影響的 Internet Explorer 文件模式
IE9 標準

**功能的影響程度
嚴重性:**高(在事件移除之後)
**可能性:**高(在事件移除之後)

描述
Microsoft 會指出「已過時」的功能,以警告未來不要使用該些功能,以便淘汰這些功能:

  • 如果 Windows Internet Explorer 9 中有加入新標準支援,則 MSDN 上相關聯的功能文件會標示為「已過時」,並且會包含替代標準的連結。
  • 如果某功能是 Web 平台功能,所有文件模式都會一直支援該功能到只有極少數的網站使用它為止。

下面的文件物件模型 (DOM) 事件功能在 IE9 標準文件模式中已過時,並且預計在下一個主要版本的最新標準模式中移除。

已過時的功能 替代的 W3C 標準
attachEvent AddEventListener
detachEvent removeEventListener
createEventObject createEvent
fireEvent dispatchEvent

適用於 Internet Explorer 9 的應用程式開發指南和工具

本節的《Windows Internet Explorer 9 相容性操作手冊》提供幫助確保您的應用程式可以在新版的 Windows Internet Explorer 如期運作的指南。涵蓋的主題提供改進跨瀏覽器功能的資訊,以及如何在新功能與具有現有網頁的網站相容性功能之間制衡的建議。

《Internet Explorer 9 相容性檢視清單》

受影響的 Internet Explorer 文件模式
IE9 標準 | IE8 標準 | IE7 標準 | Quirks

問題描述
針對舊版 Internet Explorer 設計的網站在現行版本中不一定都能如預期顯示。我們在 Internet Explorer 8 透過新增「相容性檢視」功能解決了這個問題,此功能可讓使用者「還原」為平台先前的瀏覽器版本,也就是模擬 IE7 的標準模式。

相容性檢視解決的不相容問題的例子,包括不正確的瀏覽器或功能偵測等。現在許多網站都是使用瀏覽器偵測,而不是功能和行為偵測來提供 IE 標記,而此類標記與 IE9 標準模式或與其他瀏覽器並不互通。這在以 IE9 標準模式呈現的網站上可能會導致嚴重的功能中斷。

工具描述
相容性檢視可讓針對舊版網頁瀏覽器設計的內容在新版的 Internet Explorer 中適當呈現。相容性檢視 (CV) 清單不需進一步的互動,即會自動將網站的內容顯示在相容性檢視中。Internet Explorer 9 包含對相容文件模式的支援,以及一份類似於 Internet Explorer 8 中隨附的相容性檢視清單。

我們只會將處於以下狀況的網站新增到相容性檢視清單:

  • 設計為執行舊版的 IE
  • 在 IE9 標準模式中運作不佳
  • 不宣告X-UA-Compatible 中繼標記或標頭

相容性檢視現在會解決功能偵測和條件式註解。

**功能切換:**為了讓網站在 IE9 的標準模式內順利運作,而不是還原為 IE8 或 IE7 文件模式,IE9 相容性檢視清單包含一項新功能,稱為「featureSwitch」。這會使 IE9 標準模式中的特定 API 表現得跟在舊版 IE 版本中無異。

我們打算在開發人員在將他們的網站更新,以便跨瀏覽器使用相同標記時立即移除功能切換。對於透過測試找到的對許多網站都有影響的特定高衝擊變更,我們會保留功能切換。

我們不會針對任何行為變更建立功能切換,而且網站無法選擇選擇使用它們。反而應該由開發人員透過 X-UA-Compatible 中繼標記或標頭選擇使用 IE7 或 IE8 文件模式,使他們的網站在更新至 IE9 的標準模式之前能夠相容。

**其他相容性檢視清單功能:**除了提供功能切換和關閉條件式註解的功能外,IE9 相容性檢視清單還可以:

  • 將網站顯示在相容性檢視中,就跟 IE8 相容性檢視清單一樣
  • 變更文件模式,讓網站以 IE7 或 IE8呈現

指引和工具用法

IE9 相容性檢視清單是 Microsoft.com 上的 XML 檔案。我們可以每天更新該清單,也就是說我們可以迅速配合開發人員的要求移除已更新的網站。使用者會自動取得更新。

您可以瀏覽至下面的檔案路徑在您的本機機器上檢視 IE9 相容性檢視:

File:\\%LOCALAPPDATA%\Microsoft\Internet Explorer\IECompatData\iecompatdata.xml

為了繼續縮小相容性檢視清單的大小,**我們建議網站開發人員立即更新他們的網站,讓網站可以在IE9的標準模式內順利運作,並且提供他們用於其他瀏覽器的相同標記。**網站在能夠更新之前應該宣告 X-UA-Compatible 值,至少利用 IE7 或 IE8 文件模式。

動作:

  • 最後,當您的更新在網路上線時,附上下列資訊寄電子郵件到 iepo@microsoft.com,要求將您的網站從 IE9 相容性檢視清單中移除:
    • 擁有者名稱
    • 企業稱號
    • 電子郵件地址
    • 電話號碼
    • 公司名稱
    • 街道地址
    • 網址

Microsoft 將檢閱所提供的資訊,並在下次排定的清單更新將您的網站從相容性檢視清單中移除。

《更新現有程式碼以用於不同瀏覽器》

受影響的 Internet Explorer 文件模式
IE9 標準 | IE8 標準 | IE7 標準 | Quirks

描述
在開發 Windows Internet Explorer 應用程式時,必須在新功能與具有現有網頁的網站相容性功能之間取得平衡。Windows Internet Explorer 8 推出的文件相容性模式可使從舊式實作轉換到新標準的過程更加輕鬆。

指導方針
如果您現有的網頁可在 Windows Internet Explorer 7 或Internet Explorer 8 中正確運作,而您想要有個短期的解決方案讓頁面也能用於 Windows Internet Explorer 9,您有兩個選擇:

  • 在每個網頁中新增相容性模式 meta 元素,強制 Internet Explorer 9 將頁面轉譯為類似於舊式的 Internet Explorer 頁面。
  • 設定網頁伺服器隨著每個網頁傳送與 meta 元素相當的自訂 HTTP 回應標頭,自動新增相容性。

這些修正方法都只是暫時的解決之道。最終您還是應該修改您的網站,使其執行 Internet Explorer 9 和之後版本中提供的標準基礎程式碼,以及由較早之 Internet Explorer 版本所傳承下來的程式碼。

永久的解決方案是,使用功能和行為偵測功能來撰寫能夠可靠地配合跨瀏覽器差異的程式碼。功能偵測會測試瀏覽器在您使用某功能前是否有支援該功能,而行為偵測則會測試已知問題再套用因應措施。

遵守這些標準後,您的網站將可在舊版的 Internet Explorer、Internet Explorer 9 及未來發行的任何版本下順利運作。

《使用功能和行為偵測》

受影響的 Internet Explorer 文件模式
IE9 標準 | IE8 標準 | IE7 標準 | Quirks

描述
由於 Windows Internet Explorer 存在許多版本,您應該採用跨瀏覽器的最佳作法。大多數網頁都包含針對不同瀏覽器而寫的程式碼,也包含可判定哪些程式碼在哪裡執行,以及頁面在不同的瀏覽器上要如何執行的各種測試。

Windows Internet Explorer 9 減緩了跨瀏覽器差異所造成的衝擊,並且讓您跨瀏覽器使用相同的標記。要使用相同的標記,每個瀏覽器都必須支援正確的功能,使相同的 HTML、JavaScript 和 CSS 程式碼都能「順利運作」,而您必須適時偵測並在這些功能可用時使用它們。本主題將說明如何使用功能和行為偵測功能來撰寫能夠可靠地配合跨瀏覽器差異的程式碼。

指導方針
下節將說明在確定網頁跨瀏覽器相容時應該和不應該使用的方法。

建議方法:
請使用下列的偵測方法,以更可靠的方式偵測錯誤來源,以及確定網頁在不同瀏覽器間都相容:

  • **功能偵測:**測試瀏覽器在您使用某功能前是否有支援該功能。功能偵測讓您不用事先知道每個瀏覽器的功能,就能夠使跨瀏覽器程式碼「順利運作」。例如,jQuery 架構幾乎完全是仰賴功能偵測。有關您可以如何在自己的網站上使用 jQuery 功能的詳細資訊,請參閱 jQuery.support 文件。
  • **行為偵測:**測試已知問題再套用因應措施。jQuery 也是使用行為偵測來執行測試找出已知問題,以判斷是否需要特定的因應措施。

不建議方法:

  • **偵測特定瀏覽器:**請勿使用瀏覽器的識別 (例如 navigator.userAgent) 來變更頁面的行為。如果您以特定瀏覽器為主來變更程式碼,頁面可能無法輕易適應變更,而且可能在有新瀏覽器發行時損毀。在其他情況下,頁面會使用舊式因應措施,即使該因應措施已經不需要了也一樣。
  • **假設不相關的功能:**請勿針對某功能執行功能偵測,然後使用不同的功能。網站若是對某功能執行功能偵測,然後沒有測試是否支援便使用其他功能會有此方面的問題。