jQuery代码优化之基本事件
事件模型
说到事件，就要追溯到网景与微软的“大战”了。当时，事件模型还没有标准，两家公司的实现就是事实标准。网景在Navigator中实现了“事件捕获”的事件，而微软则在IE中实现了一个基本上相反的事件系统，叫做“事件冒泡”。这两种系统的区别在于当事件发生时，相关元素处理(响应)事件的优先权不同。
下面举例说明这两种事件机制的区别。假设文档中有如下结构：
代码如下:
<p>
<span>
<a>...</a>
</span>
</p>
因为这三个元素是嵌套的，所以单击了a，实际上也就单击了span和p。换句话说，这三个元素都应该有处理单击事件的机会。在事件捕获机制下，处理这个单击事件的优先次序是：p > span > a;而在事件冒泡机制下，处理这个单击事件的优先次序则是：a > span > p。
后来，W3C的规范要求浏览器同时支持捕获和冒泡机制，并允许开发人员选择把事件注册到哪个阶段。于是就有了下面这个注册事件的标准方法：
target.addEventListener(type, listener, useCapture Optional );
其中：
◆ type：字符串，表示监听的事件类型
◆ listener：监听器对象(Script函数)，在指定事件发生时可以收到通知
◆ useCapture：布尔值，是否注册到捕获阶段
在实际应用开发中，为了确保与IE(因为它不支持捕获)兼容，useCapture一般都指定为false(默认值也是false)。换句话说，只把事件注册到冒泡阶段;对于上面那个简单的例子来说，响应顺序就是：a > span > p。
冒泡的副作用
如前所述，IE的冒泡事件模型基本上成为了事实标准。但冒泡有一个副作用。
仍以前面的文档结构为例，假设它是界面中的一个菜单项，我们希望用户鼠标离开p时隐藏菜单。于是，我们给p注册了一个mouut事件。如果用户鼠标是从p离开的，那么一切正确。而如果用户鼠标是从a或span离开的，问题就来了。因为由于事件冒泡，从这两个元素开始分派的mouseout事件都会传播到p，从而导致鼠标并没有离开p，菜单就提前隐藏了。
当然，冒泡的副作用不难避免。比如，给p内部的每个元素都注册mouseout事件，并使用.stopPropagation()方法阻止事件进一步传播。对于IE，就得将事件对象的cancelBubble属性设置为false，取消事件冒泡。不过，这仍然回到自己处理浏览器不兼容性问题的老路上了。
优化方案
为了避免冒泡的副作用，jQuery提供了mouseenter和mouseleave事件，就使用它们来代替mouseover和mouseout吧。
下面这个摘自jQuery的内部函数withinElement，就是为mouseenter和mouseleave提供支持的。翻译了一下注释，仅供大家参考。
代码如下:
// 下面这个函数用于检测事件是否发生在另一个元素的内部
// 在 jQuery.event.special.mouseenter 和 mouseleave 处理程序中使用
var withinElement = function( event ) {
// 检测 mouse(over|out) 是否还在相同的父元素内
var parent = event.relatedTarget;
// 设置正确的事件类型
event.type = event.data;
// Firefox 有时候会把 relatedTarget 指定一个 XUL 元素
// 对于这种元素，无法访问其 parentNode 属性
try {
// Chrome 也类似，虽然可以访问 parentNode 属性
// 但结果却是 null
if ( parent && parent !== document && !parent.parentNode ) {
return;
}
// 沿 DOM 树向上
while ( parent && parent !== this ) {
parent = parent.parentNode;
}
if ( parent !== this ) {
// 如果实际正好位于一个非子元素上面，那好，就处理事件
jQuery.event.handle.apply( this, arguments );
}
// 假定已经离开了元素，因为很可能鼠标放在了一个XUL元素上
} catch(e) { }
},
结论
在jQuery里，可以使用mouseenter和mouseleave事件来避免事件冒泡的副作用。