Захват событий и всплытие событий [дубликаты]

В прошлом это была проблема с платформой, в Internet Explorer использовалась пузырчатая модель, а Netscape был больше связан с захватом (но поддерживал и то, и другое).

Модель W3C требует, чтобы вы могли выбирать, какой из них вы хотите.

Я думаю, что всплывающая подсказка более популярна, потому что, как уже говорилось, есть некоторые платформы, которые поддерживают только всплывающую подсказку...и это имеет смысл как режим "по умолчанию".

Какой из них вы выберете, во многом зависит от того, что вы делаете и что имеет для вас смысл.

Читая JavaScript: The Definitive Guide, 5th Edition, я наткнулся на пример 17-4 на странице 422, в котором определяется функция для перетаскивания абсолютно позиционированных элементов. В примере функция drag() вызывается в атрибуте onmousedown элемента документа. Функция перемещает элемент в зависимости от изменения положения мыши, которое запрашивается обработчиками, добавленными к корневому элементу документа для захваченных событий mousemove и mouseup. Они фиксируют эти события в документе по следующей причине:

Важно отметить, что обработчики mousemove и mouseup зарегистрированы как захватывающие обработчики событий, потому что пользователь может перемещать мышь быстрее, чем элемент документа может следовать за ним, и некоторые из этих событий происходят за пределами исходного целевого элемента.

Это предполагает преимущество в более быстром реагировании при регистрации событий.

Этот тест предполагает небольшое преимущество в производительности при использовании захвата по сравнению с пузырьком. Даже без уничтожения события, как только оно будет обработано, однако, когда оно было оставлено, оно было маргинальным. Я полагаю, что сложный DOM преувеличил бы разницу в производительности между ними.

Эта ссылка дает четкое объяснение: https://www.quirksmode.org/js/events_order.html

Вы, веб-разработчик, можете выбрать, регистрировать ли обработчик событий на этапе захвата или на этапе всплытия. Это делается с помощью метода addEventListener(), описанного на странице «Расширенные модели». Если его последний аргумент равен true, обработчик событий устанавливается для фазы захвата, если он ложен, обработчик событий устанавливается для фазы всплытия.

Предположим, вы делаете

element1.addEventListener('click',doSomething2,true)
element2.addEventListener('click',doSomething,false)

Если пользователь нажимает на element2, происходит следующее:

Событие клика начинается на этапе захвата. Событие проверяет, имеет ли какой-либо элемент-предок element2 обработчик события onclick для фазы захвата. Событие находит его в element1. doSomething2() выполняется. Событие спускается к самой цели, обработчики событий для фазы захвата больше не найдены. Событие переходит в фазу всплытия и выполняет функцию doSomething(), зарегистрированную в element2 для фазы всплытия. Событие снова перемещается вверх и проверяет, есть ли у какого-либо элемента-предка цели обработчик событий для фазы всплытия. Это не так, поэтому ничего не происходит. Обратное было бы

element1.addEventListener('click',doSomething2,false)
element2.addEventListener('click',doSomething,false)

Теперь, если пользователь нажимает на element2, происходит следующее:

Событие клика начинается на этапе захвата. Событие проверяет, имеет ли какой-либо элемент-предок element2 обработчик события onclick для фазы захвата, и не находит его. Событие спускается к самой цели. Событие переходит в фазу всплытия и выполняет функцию doSomething(), зарегистрированную в element2 для фазы всплытия. Событие снова перемещается вверх и проверяет, есть ли у какого-либо элемента-предка цели обработчик событий для фазы всплытия. Событие находит его в element1. Теперь выполняется doSomething2(). Совместимость с традиционной моделью В браузерах, поддерживающих W3C DOM, традиционная регистрация событий

element1.onclick = doSomething2;

рассматривается как регистрация в фазе пузыря.

Использование всплывающих событий Немногие веб-разработчики сознательно используют захват событий или всплывающие сообщения. В веб-страницах, которые создаются сегодня, просто нет необходимости позволять всплывающему событию обрабатываться несколькими разными обработчиками событий. Пользователи могут быть сбиты с толку несколькими вещами, происходящими после одного щелчка мыши, и обычно вы хотите, чтобы ваши сценарии обработки событий были разделены. Когда пользователь нажимает на элемент, что-то происходит, когда он нажимает на другой элемент, происходит что-то еще.

Конечно, это может измениться в будущем, и хорошо иметь доступные модели, совместимые с предыдущими версиями. Но основное практическое применение захвата и всплытия событий сегодня — это регистрация функций по умолчанию.

Я не уверен, но я почти уверен, что все, что вы можете сделать с пузырем, вы можете сделать с захватом, и наоборот.

Идея о том, что некоторые события будут всплывать, а некоторые записываться в одном и том же приложении, звучит как хороший способ сделать вещи очень запутанными. Я хочу сказать, что я не думаю, что пузырение против захвата действительно имеет значение. Важно то, что вы выбираете один и придерживаетесь его.

API-интерфейсы W3C часто содержат такие вещи, где у них есть много функций, которые никого не волнуют. Возможно, это еще один пример того, как хорошие настройки по умолчанию могут устранить необходимость в настройке или даже целых функциях.