javascript - 需要/首选事件捕获的真实世界示例？

Question

addEventListener DOM 方法支持第三个可选的 bool 参数 (useCapture)，以指示该函数是否应使用事件冒泡 或事件捕获作为传播方式。在 this article很好地显示了差异(单击示例并查看代码)。

从关于 SO 和博客文章的其他问题，我得出结论，事件冒泡是首选，主要是因为 IE8- 不支持它。

假设我只需要支持 IE9+，在什么情况下事件捕获是必要的或优先于事件冒泡？也就是说，在什么情况下让事件先在最外层元素上执行，再在最内层元素上执行会更好呢？我正在寻找一个简单的真实示例来演示事件捕获的使用...

Answer 1

事件捕获曾经是 Internet Explorer 浏览器之外的唯一选项:

One of the major differences of the back then two important browsers was how they handled events. Microsoft worked with the bubbling phase - meaning the event first hit on the target element and then traverse the whole DOM upwards hitting on the parent nodes whereas Netscape did it the exact other way - meaning the event first passes the parent elements and then runs down to the target element - capturing. This caused developers in the early days a lot of trouble and the W3C finally specified an approach where both kind of works and can be used at free will.

当不支持冒泡时，事件捕获在事件委托(delegate)中很有用。例如:

Some events, such as focus, don't bubble but can be captured.The inline handler on the target element triggers before capture handlers for the target element.

Many newly specified events in the web platform (such as the media events) do not bubble, which is a problem for frameworks like Ember that rely on event delegation. However, the capture API, which was added in IE9, is invoked properly for all events, and does not require a normalization layer. Not only would supporting the capture API allow us to drop the jQuery dependency, but it would allow us to properly handle these non-bubbling events. This would allow you to use events like playing in your components without having to manually set up event listeners.

自定义事件和冒泡存在以下问题:

Currently, Ember relies on jQuery for event handling, doing so comes with several costs:

jQuery silently changes inline handlers to bubble handlers.
    This changes expected invocation order
    This can cause automated tests to fail
Events triggered via jQuery.trigger trigger handlers in a different order than events triggered by a user.
    This changes expected invocation order
    This leads to difficult to reason about and debug aberrations in behavior
    This often causes automated tests to fail
Events must flow down and bubble back up through the entire DOM before being detected by the Ember application, and then must undergo an expensive delegation process that is effectively re-bubbling to find the right handler.
Handlers attached directly within components or by non-ember plugins take precedent over handlers attached by Ember, whether this was desired or not.

    This causes component handlers to have far-reaching side-effects
    This leads to difficult to reason about and debug aberrations in behavior
    This often causes automated tests to fail

媒体播放器焦点=>播放预处理/后处理事件流将是一个简单的用例。

The mechanics of the capturing phase make it ideal for preparing or preventing behavior that will later be applied by event delegation during the bubbling phase. And that’s how we’re going to use it here—to initialize the sortable in response to a mouse click, but just before the event starts bubbling and other handlers have a chance to deal with it.

To make use of capturing, we have to go down to the metal. jQuery’s event methods only work for bubbling and don’t let us tap into the capturing phase. The capturing handler looks like:

    document.addEventListener("mousedown", function(event) {
      if ($(event.target).closest(".sortable_handle").length) {
         $("article.todolist, section.todolists").sortable();
         }
      }, true);

引用资料

• Domina Github Repo: Readme - Event Propagation

• EmberJS RFC: Capture Based Eventing

• EmberJS RFC: Internet Explorer

• MDN: Event.eventPhase

• Using event capturing to improve Basecamp page load times – Signal v. Noise

• Bubbling, foreign events and Firefox: Index

• Event capture and bubbling