一說到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的特殊之處敬請說來。