IE 瀏覽器的創新

lync.in發表於2012-08-25
瀏覽器

譯者按：IE 曾是 Web 創新的先驅，但最近幾年因為對 Web 標準的支援落後於其他瀏覽器以及低版本 IE 的各種 bug 而被人詬病。知名Web開發者 Nicholas C. Zakas 帶我們回顧了 IE 在 Web 發展過程中扮演的輝煌角色，讓我們能以一個更客觀的眼光來看待 IE。看完這篇文章，也許大家都會對 IE 瀏覽器有一定的改觀，這也是我翻譯這篇文章的目的。以下是全文。

 

在 Internet Explorer 成為大家都恨之入骨的瀏覽器的很久以前，它曾是整個網際網路的創新驅動力。有時候我們很難記得那些在 IE 6 成為全世界 web 開發者的災難之前 IE 所作的貢獻。不管你信不信，正因為有了 IE 4—6，才會有我們現在所知的 web 開發。IE 的一些獨特的功能過去就曾是事實標準，後來成為了官方標準最終進入了 HTML5 規範。人們也許很難相信，對於我們現在認為理所應當的功能，其中有很大一部分都應該要想到 IE，如果我們快速地回顧一下歷史，就知道的確如此。

 

DOM

如果 IE 是一個人人都痛恨的瀏覽器，那麼「文件物件模型」（DOM）就是人人都痛恨的 API 了。你可以說 DOM 過於繁瑣、不適合 JavaScript 甚至是有些荒謬，而且這些也都沒錯。然而，DOM 還是給了開發者通過 JavaScript 來訪問網頁的每個部分的途徑。曾經你一度只能通過 JavaScript 訪問頁面中某些特定的元素。IE 3 和 Netscape 3 只允許程式訪問表單元素、圖片以及連結。Netscape 4 改進了這一點，把程式可訪問的範圍通過 document.layers 擴充套件到了它特有的 layer 元素。IE 4 作了進一步改進，把這個範圍通過 document.all擴充套件到了頁面的所有元素。

從很多方面來說，document.all 算是 document.getElementById() 的最初版本。你還是要使用元素的 ID 來通過 document.all 訪問它，例如 document.all.myDiv 或是 document.all["myDiv"]。最主要的區別就是 IE 使用了一個集合而非方法，而這和其他當時的訪問方法比如 document.images 及 document.forms 是相吻合的。

IE 4 也第一個引入了用 document.all.tags() 來通過標籤名字獲取一個元素列表的功能。無論從哪點來看，這都是 document.getElementsByTagName() 的最初版本，而且工作方式完全相同。如果你想獲取所有的 div元素，你可以使用 document.all.tags("div")。甚至在 IE 9 中，這個方法仍然作為document.getElementsByTagName() 的一個別名存在。

IE 4 同時也為我們引入了可能是有史以來最流行的私有 DOM 擴充套件：innerHTML。看起來微軟的那幫人是認識到了通過程式設計手段來建立一個 DOM 有多麼痛苦，所以把這個便捷方法，連同 outerHTML 一起提供給我們。事實證明這兩個方法都非常有用，已經在 HTML5 中被標準化了[1]。隨它們一同而來的用來處理純文字的 API——innerText 以及 outerText——同樣被證明足夠有影響力，因為 DOM Level 3 已經引入了與 innerText行為相似的 textContent[2]。

按照同樣的思路，IE 4 引入了 insertAdjacentHTML()，這是又一種將 HTML 插入文件中的方法。雖然這花了更長的時間，但最終也被編入了 HTML5[3]，而且目前已被各瀏覽器廣泛支援。

microsoft internet explorer 8

事件

在開始時，JavaScript 並沒有事件機制。網景和微軟都作出了嘗試，並且分別得出了不同的模型。網景給我們帶來了事件捕獲，其思想是一個事件先傳送到視窗，然後是文件，然後一個個直到最終到達預期的目標。網景瀏覽器 6 以前的版本都僅支援事件捕獲。

微軟採取了一個相反的方法，設計出了事件冒泡。他們認為一個事件應該先從實際的目標出發，然後在上層節點觸發直到文件。IE 9 以前的瀏覽器僅支援事件冒泡。雖然隨著官方的 DOM 事件規範發展，同時包含了事件捕獲和事件冒泡，但大多數 web 開發者都只使用事件冒泡，而把事件捕獲僅僅留在 JavaScript 類庫中的一些解決方案和小技巧中使用。

除了創造了事件冒泡以外，微軟還創造了一系列後來也最終被標準化的額外事件：

●contextmenu – 當使用滑鼠副按鍵點選一個元素時觸發。在 IE 5 中首次出現，後來被編入了 HTML5[4]。現在已被所有主流瀏覽器所支援。

●beforeunload – 在 unload 事件前觸發，允許你阻斷頁面的退出。最初由 IE 4 引入，現在也為 HTML5 的一部分[4]。

●mousewheel – 在滑鼠滾輪（或類似裝置）被使用時觸發。首個支援此事件的瀏覽器是 IE 6。就像其他一樣，目前也是 HTML5 的一部分[4]。唯一不支援此事件的主流桌面瀏覽器是 Firefox（但其支援一個可用來替代的 DOMMouseScroll 事件）。

●mouseenter – mouseover 的非冒泡版本，被微軟在 IE 5 中引入，用來克服 mouseover 使用時帶來的困擾。這個事件已被 DOM Level 3 事件規範正規化[5]。同樣被 Firefox 及 Opera 支援，但 Safari 和 Chrome 都（暫時？）不支援。

●mouseleave – 與 mouseenter 對應的 mouseout 的非冒泡版本。在 IE 5 中被引入，目前被 DOM Level 3 事件規範標準化[6]。瀏覽器支援和 mouseenter 一樣。

●focusin – focus 事件的冒泡版本，用來幫助更好地管理頁面上的聚焦行為。最初在 IE 6 中被引入，現在已成為 DOM Level 3 事件規範的一部分[7]。目前沒有被很好地支援，儘管 Firefox 關於其實現的開過一個 bug。

●focusout – blur 事件的冒泡版本，用來幫助更好地管理頁面上的聚焦行為。最初在 IE 6 中被引入，現在已成為 DOM Level 3 事件規範的一部分[8]。和 focusin 一樣，沒有良好支援但 Firefox 接近了。

 

<iframe>

框架一開始是作為一個私有功能被引入 Netscape Navigator 2 的。這包括了 <frameset>、<frame> 以及<noframes>。其背後的思想其實很簡單：那時每個人都在使用調變解調器，往返於伺服器之間的代價頗高。主要的應用場景是提供一個只載入一次的帶有導航元素的框架，然後其他框架可以由導航控制來做單獨的變化。利用將導航作為一個單獨頁面來節省伺服器渲染時間以及資料傳輸量在當時是一個巨大的勝利。

IE 3 也支援框架，因為他們當時在 web 上正變得非常流行。但是，微軟為此功能增加了自己的私有標籤：<iframe>。這個元素背後的基本想法是在一個頁面中嵌入另一個頁面。在 Netscape 的實現中你需要建立三個頁面（導航頁、內容頁以及框架集）來實現靜態導航，而在 IE 中你只需要兩個頁面（帶有導航的主頁面以及<iframe> 中的內容頁）就能建立出同樣的功能。起初，這曾經是 IE 和 Netscape Navigator 間的主戰場之一。

<iframe> 逐漸變得更流行，因為它在建立框架集時更加省事。Netscape 在版本 4 中引入了和 <iframe> 功能十分類似的 <ilayer> 來進行反擊。當然，<iframe> 最終勝出並且成為了目前 web 開發的一個重要部分。網景的框架和微軟的 <iframe> 都曾被 HTML4 標準化，但網景的框架後來在 HTML5 中被廢棄（不建議使用）了。

 

XML 與 Ajax

儘管 XML 已經像很多人所料的那樣在現今的 web 上被大量使用，但是對 XML 進行支援的領路人仍然是 IE。它是第一個支援在客戶端通過 JavaScript 進行 XML 解析以及 XSLT 變換的瀏覽器。不幸的是，它是通過 ActiveX 物件來表示 XML 文件以及 XSLT 處理器的。但 Mozilla 的人顯然認識到了其中的可取之處，因為他們後來用DOMParser、XMLSerializer 和 XSLTProcessor 創造了類似的功能。其中前兩個已經成為了 HTML5 的一部分[9]。雖然基於標準的 JavaScript XML 處理方式和 IE 提供的版本差異較大，但它無疑是深受 IE 影響的。

客戶端的 XML 處理都都是 IE 對 XMLHttpRequest 的實現的一部分，最開始由 IE 5 以 ActiveX 物件的形式引入。其中的想法是希望可以在一個網頁中從伺服器獲取一個 XML 文件並且允許用 JavaScript 把這個 XML 當做 DOM 來進行處理。IE 的版本需要你使用 new ActiveXObject("MSXML2.XMLHttp")，這也使得它依賴於版本字串，而且讓開發者要費盡功夫去測試、使用最新版本。再一次，Firefox 站出來，通過建立一個當時還是私有的、與 IE 版本介面完全同名的 XMLHttpRequest 物件來清理這一片混亂。此後其他瀏覽器複製了 Firefox 的實現，最終使得 IE 7 也增加了一個不需要使用 ActiveX 的版本。當然，使得每個人為 JavaScript 感到振奮的 Ajax 革命背後的驅動力正是 XMLHttpRequest。

 

CSS

當想到 CSS 的時候，你可能不會過多地想到 IE——畢竟它對於 CSS 的支援往往是滯後的（至少直到 IE 10 都是如此）。然而，IE 3 卻是第一個實現了 CSS 支援的瀏覽器。當時，網景正在力推另一個類似的提案：JavaScript 樣式表（JSSS）[10]。從名稱就可以看出，這個提案用 JavaScript 來定義關於頁面的樣式資訊。Netscape 4 引入了 JSSS 和 CSS，整整比 IE 落後了一個版本。其中對 CSS 的支援並不盡如人意，常常需要將樣式翻譯為 JSSS 以便應用[11]。這也意味著在 Netscape 4 下，如果 JavaScript 被禁止了，CSS 也無法正常工作。

而那時 IE 對 CSS 的實現僅限於字型族、字號、顏色以及背景，但這個實現卻是優質且可用的。與此同時，Netscape 4 的實現卻很容易出問題、難以使用。是的，在很小的程度上，IE 導致了 CSS 的成功。

IE 還給我們帶來了其他最終被標準化的對 CSS 作的創新：

●text-overflow – 用來在文字超出容器大小時顯示省略號。在 IE 6 中首次出現並已在 CSS3 中被標準化[12]。目前已被各主流瀏覽器支援。

●overflow-x 與 overflow-y – 允許你在兩個獨立的方向上對內容溢位進行控制。這個屬性在 IE 5 中首次出現，後在 CSS3 中規範化了[13]。目前已被各主流瀏覽器支援。

●word-break – 用來指定詞語之間的換行規則。最初在 IE 5.5 中出現，現已被 CSS3 規範化[14]。除 Opera 外的所有主流瀏覽器均支援。

●word-wrap – 指定了瀏覽器是否應該在詞語中間換行。在 IE 5.5 中被創造出來，現已被 CSS3 標準化為了overflow-wrap[15]，儘管所有主流瀏覽器都以 word-wrap 的形式支援它。

另外，許多 CSS3 中新的視覺效果都應該感謝 IE 所奠定的基礎。IE 4 引入了私有的 filter 屬性，從成為了第一個可以做下面這些事的瀏覽器：

●根據 CSS 的指示來生成漸變（CSS3：漸變）

●用 alpha 濾鏡來建立半透明元素（CSS3：opacity 以及 RGBA）

●將一個元素旋轉任意的角度（CSS3：用 transform 配合 rotate()）

●為一個元素應用陰影（CSS3：box-shadow）

●為一個元素應用一個矩陣變換（CSS3：用 transform 配合 matrix()）

除此之外，IE 4 有一個被稱為「過渡」的功能，它允許你用濾鏡建立一些基本的動畫。這個功能主要是基於通常在 PowerPoint 中可用的過渡功能，例如淡入或淡出、棋盤變換等等[16]。

所有這些功能都以某種方式成為了 CSS3 的主要功能。在 1997 年釋出的 IE 4 就有了這些功能，而我們現在才開始在其他瀏覽器中享受到這些功能，實在是很驚人的。

 

其他對 HTML5 的貢獻

HTML5 中很大一部分都來自 IE 及其引入的 API。這裡有一些本文之前還沒提到過的內容：

●拖放 – HTML5 中最酷的部分之一就是原生的拖放功能[17]。這個 API 源自 IE 5，而且在 HTML5 中已有描述，且變化非常小。主要的區別是增加了 draggable 屬性來把任意元素標記為可拖放的（IE 用了一個 JavaScript 呼叫——element.dragDrop() 來做這件事）。除此之外，這個 API 與原始版本近乎相同，目前已被各主流桌面瀏覽器所支援。

●剪貼簿的訪問 – 現在已從 HTML5 中分離出了自己的規範[18]，賦予了瀏覽器在某些情況下訪問剪貼簿的能力。這個 API 最初出現在 IE 6 中，隨後被 Safari 模仿，它將 clipboardData 從 window 物件中取了出來，放到了剪貼簿事件的 event 物件中。Safari 的改動被保留為 HTML5 版本的一部分，而且剪貼簿的訪問在所有除 Opera 以外的主流瀏覽器中也都已被支援。

●富文字編輯 – 用 designMode 進行富文字編輯是在 IE 4 中被引入的，因為微軟希望給 Hotmail 使用者們一個更好的文字編輯體驗。後來，在 IE 5.5 引入了 contentEditable，以用作一個更輕量級的進行富文字編輯的方法。隨之而來的是可怕的 execCommand() 方法以及它的一些附屬方法。不論好壞，這個富文字編輯的 API 已在 HTML5 中被標準化[19]，而且目前已經被所有主流桌面瀏覽器以及移動 Safari 和 Android 瀏覽器所支援。

 

結論

儘管嘲笑 IE 很簡單也很流行，但事實上，如果不是它所作的貢獻，我們不會擁有我們目前所知的 web。如果沒有 XMLHttpRequest 和 innerHTML web 會怎樣？它們正是 web 應用的 Ajax 革命的催化劑，許多新的功能都是基於它們構建的。可笑的是當我們回望這個已經成為網際網路上的「壞小子」的瀏覽器的歷史，會發現沒有它，我們不會處在今天所在的位置。

是的，IE 自身有瑕疵，但對於網際網路的歷史的絕大部分時間，它都是推動技術進步的瀏覽器。現在我們處在一個大規模瀏覽器競爭以及創新的時代，卻很容易忘記我們從哪裡一路走來。所以當你下次遇見正在做 IE 相關工作的人時，請別投去羞辱和番茄。相反，要謝謝他們幫助 IE 一路走到今天，也使 web 開發者成為世界上最重要的工作之一。

 

參考文件

 

相關文章