一说到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的特殊之处敬请说来。
