Javascript的事件捕获和事件冒泡

其实事件处理有两种模型。一种叫冒泡型，也就是上面我们看到的例子，顺序是从里到外”div” -> “body” -> “html” -> “document” -> “window”。还有一种叫捕获型，顺序正好颠倒。IE是支持冒泡型，据说历史上的Netscape是支持捕获型。那我们主流的W3C标准呢？答案是都支持，默认是冒泡型。这要怎么理解？我们先来看下W3C DOM事件流的过程：

当一个事件发生时，先进入捕获阶段，也就是从最外层开始，依次向里传播事件，一直到触发事件的目标元素（上例中的div child)。随后再进入冒泡阶段，从触发事件的元素开始，依次向外传播，直到最外层元素。那么为什么我们在前面的例子中看不到事件捕获的阶段呢？这里我们要先说另外一个概念。

添加事件绑定

上面的例子是将onclick事件属性设置为alertName(e)方法，这样的事件绑定方法一般不推荐，因为会覆盖之前所绑定的其他函数。我们建议采用addEventListener方法。我们将上例中绑定事件的代码做如下改动：

child = document.getElementById(‘child’);
parent = document.getElementById(‘parent’);
child.addEventListener(“click”, alertName); // 注意，这里要写click，不是onclick
parent.addEventListener(“click”, alertName);

addEventListener方法的第一个参数是事件名称，第二个参数是响应函数。打开浏览器点击下，是不是跟之前用onclick绑定的效果一样啊？那这么做的好处是什么呢？我们试试在上段代码的后面添加下面的代码：

function alertAgain(e) {
alert(this.id + “, again”)
}
child.addEventListener(“click”, alertAgain);

再次点击内层蓝色div部分，你会看到该元素上绑定的两个点击事件方法都响应了，响应的顺序同代码中绑定的顺序一致。所以，使用addEventListener就不会覆盖掉之前已绑定的方法。

捕获阶段事件响应

介绍完addEventListener方法的作用，就要说下，这个方法其实有第三个参数的。参数名称叫useCapture，类型是布尔型。从名称里估计大家就猜到了，如果将它设为true的话，事件处理将会是捕获型的，也就是事件将会在捕获阶段响应，而不是冒泡阶段响应。我们将上面例子中addEventListener部分改动一下：

child = document.getElementById(‘child’);
parent = document.getElementById(‘parent’);
child.addEventListener(“click”, alertName); // 注意，这里要写click，不是onclick
parent.addEventListener(“click”, alertName, true);
parent.addEventListener(“click”, alertAgain);

测试一下，当点击内层蓝色部分时，外层div的alertName方法先响应了，然后是内层div的alertName方法，最后是外层div的alertAgain方法。也就是说，语句parent.addEventListener("click", alertName, true);注册的事件，被提前到捕获阶段响应，即最外层的响应会先被执行。

注意了，IE8之前是不支持addEventListener的，所以只能用attachEvent方法来添加事件绑定，代码如下：

child = document.getElementById(‘child’);
parent = document.getElementById(‘parent’);
child.attachEvent(“onclick”, alertName); // 注意，这里要写onclick
parent.attachEvent(“onclick”, alertName);

attachEvent方法没有第三个参数，所以说老版本的IE只支持事件冒泡，而不支持事件捕获。即使是在后续的IE版本中可以调用addEventListener方法，但大家也要注意，里面的”this指针”的指向跟W3C标准浏览器不一样。父元素在冒泡过程中响应时，”this指针”将指向window对象，所以上面的例子在IE高版本中测试时，第二个”alert”内容会是undefined。哎，万恶的IE！

阻止事件传播

有时候，我们希望事件被响应一次就停了，不希望子元素（在捕获过程中）或者父元素（在冒泡过程中），再次响应同样的事件，这个要怎么做呢？我们还是看例子。这次我们要改动的是alertName方法。

function alertName(e) {
alert(this.id);
stopBubble(e);
}

function stopBubble(e) {
if (e && e.stopPropagation)
e.stopPropagation(); // W3C
else
window.event.cancelBubble = true; // Old IE
}

event对象上的stopPropagation方法可以阻止事件沿父节点（冒泡阶段）或子节点（捕获阶段）进一步传播。所以经过上述改动后，我们发现点击事件只会被响应一次。注意了，如果当前处理响应的节点上还有其他事件响应函数，那还是会被调用的，stopPropagation只是阻止事件往别的节点传播。万恶的IE在以前的版本中（应该是IE8往上）不支持stopPropagation，所以要用window.event.cancelBubble=true来阻止事件传播。

总结下，我们介绍了事件处理模型中的事件捕获和事件冒泡。在W3C标准中，事件响应时先进入捕获阶段从最外层元素向内传播，一直到触发事件的目标元素；然后进入冒泡阶段从目标元素向外传播，一直到最外层元素。我们可以通过addEventListener方法的第三个参数来决定事件是由捕获阶段处理还是冒泡阶段处理。而事件对象event上的stopPropagation方法可以阻止事件再次传播。说到这里，事件处理模型到底有什么意义呢？个人认为有两个好处：

1. 首先如果父元素里有很多子元素都要绑定同一个事件，而且事件的处理方法很类似，那我们完全可以只在父元素中绑定该事件作统一处理，这样代码会简洁很多。

2. 事件发生时，当前元素及其传播路径上的元素都要对该事件作不同的处理，那我们可以在各自元素上绑定对于该事件各自的处理方式。这要，当事件发生时，每个元素都只管处理自己的响应函数，有点像责任链模式。

最后，要说下两个注意点：

1. blur, focus, load, unload事件是不传播的。

2. stopPropagation不能阻止对象的默认行为传播,比如”submit”类型按钮的提交。如果你还是想做到，那就要阻止事件的默认行为。方法如下：

Baidu