換個眼界看IE，它真的有那麼可惡嗎？

一說到IE我想不少web小夥伴都避之不及，對於IE經驗不足的同窗能夠說更是 恨之入骨，撕心裂肺般的煩惱與氣憤?，被折磨的不要不要的。我感同身受，去年的個人生日願望就是， 我但願IE瀏覽器在這世界上沒有一個用戶。

這篇文章是一個追溯歷史並收集IE在web上的貢獻地位的非乾貨性文章，若是有幸被轉發分享到其餘平臺(非SF)，請到segmentfault來查看，或者關注個人github。同時，我也但願你們提出文章中的不足，加以補充，萬分感謝?。

事件冒泡

在 web3 時代(netspace3 & ie3)，就已經有了事件這個東東，當時是爲了減小服務端的壓力，後來開發者發現了一個頗有意思的問題，就是一個在一個同心圓中，若是觸發事件，那應該怎麼辦呢？

IE依然秉承着優良傳統，無論其餘人怎麼搞，我先來解決一下，以後也就出現了事件冒泡的這個概念。

隨之，netspace網景公司也提出了本身的解決方式，正好與IE大相反(有可能這哥倆誰都不服，專門對着幹)，它提出了事件捕獲的理論，也就是從外向內直至觸發元素，依次觸發事件。

雖然如今w3c標準把二者都歸入了規範，但咱們大多數仍是更偏向於冒泡，因此這個IE的點子不錯，算你厲害。

Ajax

上世紀90年代全部的網頁都是單獨的文本頁，每次交互都須要去向服務器請求新的頁面來展現信息，隨着web的不斷髮展訪問量不斷增長，服務器承受的越倆越多，當時就用java來嵌入了一個小程序(Java Applet)，它能夠動態更新頁面內容，我的認爲,java小程序過於笨重並且爲了保持平臺的語言統一，後來IE的Outlook Web Access團隊把了iframe嵌入到HTML實現了局部刷新，不久就他們就發佈了客戶端HTTP請求在當時，這是第一個能夠不用經過刷新頁面去主動發送HTTP請求的技術，並迅速應用到了IE4之中。時至今日，從ActiveXObject,XHR,Fetch，技術一直在向前走，但始終離不開AJAX的概念，因此IE起了個好頭(就是沒找)。

標準模式與混雜模式

IE5.5最早使用了標準模式與混雜模式，多是由於自身(你懂的)緣由，面對規範與本身的低版本瀏覽器(與規範差別較大，若是徹底支持規範，用戶若是更新瀏覽器徹底崩潰了)不能互融，因此這部分交給了開發者來處理，讓咱們來選擇以什麼樣的瀏覽器模式處理。

IE作出這個決定也是別無它法，若是脫離了規範就真的成爲獨腳獸了，若是支持，還得照顧低版本瀏覽器，因此這個方法無疑是最好的。也由於這樣，當時的其餘瀏覽器，IE 打了個頭，其餘瀏覽器紛紛效仿，這也算IE打了個頭提出了不一樣規範下的兼容模式。

首個使用Css

IE6是第一個徹底支持css-Level1的，它支持

• (class,id)selectors,
• descendant selectors,
• a:-only pseudo-selectors

詳情請看這篇文章。

webApp

微軟早在IE3的時候已經開始把網頁集成在desktop上了，正是由於這件事情，引發了美國政府的極度不滿，從而引起了美國訴微軟案，雖然確實有點壟斷，圖謀不軌的那種感受，但從用戶的使用角度來講這確實是一個很好的想法，過去這麼多年了，咱們不仍是在追求着SPA，PWA，想要更接近原生應用一些，但是這些Feature IE早就已經實踐過了，再看看從之前的服務器端渲染，經歷了各式各樣的新型玩法以後，發現了新大陸"SSR"，不禁暗自感嘆，技術就是一個圈，若是沒有本質上的突破，就一直繞着這圈跑，造輪子，造輪子，造輪子。

真心話

其實,IE最大的好處就是能夠下載 Firefox 與 Chrome 瀏覽器，哈哈，無論對錯，它爲web的發展貢獻了這麼多，即使之前對兼容問題比較偏執，但現代版的IE一直在跟隨W3C的腳步，但願有一天能夠像 Gecok 與 Blink 同樣高效積極支持規範。若是你們知道什麼IE的特殊之處敬請說來。