关于javascript DOM事件模型的两件事

事件捕获的实现在W3C DOM Level2的事件模型规范中，事件在DOM树中的传播过程(从根节点到目标节点)分为捕获和冒泡两个阶段。下图可以大致说明整个过程：。

(来自W3C)如果要创建一个捕获事件，在支持W3C事件模型的浏览器中，只需将addEventListener的第三个参数设置为true即可。例如，复制代码如下： document . getelementbyid(' foo ')。addeventlistener ('click '，function () {alert ('hello，world！'。);}，真)；前阵子因为想了解事件捕捉，做了一个小实验，在Firefox 2上实现了事件捕捉，在Windows和Opera 9上实现了Safari 3(当然IE不支持事件捕捉，所以……)。实验原理如下：。

ID为div1和div2的两个元素与捕获阶段的事件处理功能绑定在一起，所以：点击#div1(蓝色区域)时，“div1”要警惕；当单击#div2(黄色区域)时，“div1”应该首先被警告，然后“div2”应该被警告，因为在事件捕获阶段，事件从根元素#向下传播。但是，上述假设仅适用于Windows上的Firefox 2和Safari 3。在Opera 9中，事情会变成这样：当你点击#div1(蓝色区域)时，什么都不会发生。当你点击#div2(黄色区域)时，你会发出“div 1”的警报，然后不会再发生任何事情。通过Realazy(orz…)的指导，找到了这篇文章：《Event capture explained》，发现Opera中原来的实现是正确的。本文中有一段话是这样说的：DOM规范声明捕获事件不应该在目标上触发，因为捕获事件的想法是在事件到达目标之前检测事件。由于Gecko和Safari中的bug，主要用火狐或其他基于Gecko的浏览器测试的网络内容有时会期望捕获的侦听器会向目标发起攻击。这样的内容将在opera 7、8和当前版本的9中失败，因为它正确地执行了标准。一般的想法是，DOM规范规定捕获事件不应该在目标元素上执行，因为捕获事件的目的是在到达目标元素之前监控事件。而且火狐和Safari都是用bug实现的。让我们看看W3C的DOM Events规范中的原话：捕获事件侦听器不会被直接分派给它注册的事件目标的事件触发。因此，在整个事件传播中，执行顺序如下：父元素(如果有)中的所有catching事件从上到下执行目标元素中的冒泡事件；父元素(如果有)中的所有冒泡事件从下往上执行。了解了这些之后，也许最好不要使用事件捕捉，至少暂时不要。IE下没有addEventListener，但是它也有自己的attachEvent，叫做微软模型。它们基本相同，只是attachEvent的第一个参数(事件类型)需要加上“on”，而addEventListener则不需要。此外，attachEvent没有第三个参数，因为它不支持事件捕获。但是，attachEvent有一个致命的问题：重复绑定事件。(这是从JavaScript上的ppk学到的一个例子):复制的代码如下：函数sayhello () {alert ('hello，world！'。);} //W3C模型$('div1 ')。addEventListener('click '，sayHello，false)；$('div1 ')。addEventListener('click '，sayHello，false)；//微软Model $('div1 ')。attachEvent('onclick '，say HellO)；$('div1 ')。attachEvent('onclick '，say HellO)；在W3C模型中，相同事件处理程序的绑定将被忽略，即第二个$(“div 1”)。addeventlistener ('click '，sayhello，false)；会被忽略。在微软模型中，第二个$(“div 1”)。attachevent ('onclick '，问好)；它也会被执行，所以当你点击#div1时，警告框会弹出两次。更重要的是，在分离事件的时候，也需要分离事件两次，然后才能从#div1的点击事件中完全删除sayHello。为什么不继续使用alertID()？这是因为IE事件模型的另一个缺陷。在alertID中，此关键字用于引用与此事件处理程序绑定的元素。因此，在W3C模型中，alertID中的这个指的是#div1或#div2。但是，在Microsoft模型中，缺少对this.id的支持后，this . id将变得未定义，因为这是指此时的window对象。