IE 浏览器的创新

  • 格式:docx
  • 大小:26.90 KB
  • 文档页数:6

IE 曾是web 创新的先驱,但最近几年因为对web 标准的支持落后于其他浏览器以及低版本IE 的各种bug 而被人诟病。

雅虎的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 改进了这一点,把程序可访问的范围通过yers扩展到了它特有的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],而且目前已被各浏览器广泛支持。

事件在开始时,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]。