Методы attachEvent/addEventListener имеют ряд общих недостатков.
Во-первых, ни W3C ни Microsoft не определяют порядок срабатывания обработчиков. Несколько обработчиков одного события на элементе могут сработать в любом порядке.
На текущий момент (март 2010) addEventListener сохраняет порядок назначения обработчиков, а attachEvent в IE - нет.
elem.attachEvent("onclick", handler);
elem.attachEvent("onclick", handler2);
// может быть так, что handler2 сработает раньше handler.
// так, судя по демке ниже, ведет себя IE.
// а может быть, handler сработает раньше handler2.
// так в демо ниже ведет себя Opera
// ... вообще, порядок неопределен
Есть еще одна проблема, с которой можно столкнуться при управлении событиями: нельзя точно сказать установлен ли определённый обработчик, или нет, и какие обработчики установлены на данный момент.
В спецификации DOM 3 существует объект eventListenerList, но он слишком новый и на данный момент не поддерживается ни одним из браузеров.
Основной недостаток attachEvent заключается в том, что функция-обработчик не получает текущий элемент, на котором сработало событие, ни в каком виде.
Значение this указывает на window, а свойство event.currentTarget отсутствует.
И это достаточно важная особенность!
Например, пусть мы хотим подсвечивать divElem при клике.
Элемент divElem с разным текстом и различными ссылками, и даже с жирным текстом внутри тага <b>
Конечно, же мы повесим обработчик на divElem:
divElem.attachEvent("onclick", handler)
Но при клике из объекта события event в IE можно получить только srcElement, то есть самый глубокий кликнутый элемент. Он может быть ссылкой <a> или элементом <b>, но нам-то нужны не они, а сам divElem, чтобы его подсветить.
Обработчик, добавленный при помощи attachEvent никак не может выяснить объект, на который подвешен.
Впрочем, это легко обойти при помощи небольшого замыкания, корректно передающего указатель this:
Но этот код порождает утечку памяти в Internet Explorer 6, на который не установлено исправляющее обновление, вышедшее в июне 2007 года, из-за круговой ссылки DOM <-> JS.
Можно повесить несколько обработчиков на одно событие
Вот я только одного не могу понять:
какой толк в attachEvent и addEventListener, если все всеравно все они выполняются по одному событию? Ну напишу я 10 раз attachEvent, перечислив 10 разных функций. И что? Где это пригодится на практике? Проще объявить onclick, адрес функции и в ней уже перечислить список тех 10 функций. Разве так не проще?
На практике одно и тоже. Я не вижу ВООБЩЕ никаких плючов у attachEvent, за исключением примера с iframe
разовый обработчик не всегда есть возможность написать. Ибо элемент может не существовать, а появляться в результете каких-либо действий пользователя. Тут и поможет создание такого обработчика.
Исходники страниц браузер делает сам, поэтому не верь ему.
Если на сайте при входе будет работать сценарий, который выводит "Привет (Ваш ник(Допустим proVIDec))!", то при просмотре исходного кода браузер даст не php скрипт, а текст "Превет proVIDec".
Этот параметр объяснялся в главе введение в события:
Установка по стандарту W3C
Решение W3C работает во всех современных браузерах, кроме Internet Explorer.
Установка обработчика:element.addEventListener( имя_события, обработчик, фаза)
Удаление обработчика:element.removeEventListener( имя_события, обработчик, фаза)
Еще одно отличие от решения Microsoft это третий параметр – фаза.
Если он установлен в true, то при срабатывании события во вложенном элементе, обработчик будет вызван на фазе "перехвата", а если значение будет false, то - на фазе "всплывания". Подробнее об этом будет написано далее, в разделе этой статьи "Порядок срабатывания событий".
Немного дополню данный пост. Зачастую в функцию требуется передать некоторые параметры. Как вариант, можно расплодить глобальные переменные или создать один глобальный массив, из которого и вытягивать нужные значения. А можно решить данный вопрос и другим способом. Приведу свою функцию:
В данной функции генерится код двух других функций с подстановкой значений необходимых параметров в текстовом виде, после чего он прогоняется через eval - в результате мы имеем две функции select_region и select_city со всеми параметрами, которые им требовалось передать.
Придётся делать свой луна-парк.. Всем одна функция, в функции лист обработчиков. В принципе если сесть и подумать то легко, только как не дать убить никогда свой универсальный on<событие>?
Впрочем, это легко обойти при помощи небольшого замыкания, корректно передающего указатель this:
divElem.attachEvent("onclick", function() { handler.call(divElem) })
Вот только не всегда знаешь, какой это "divElem". А если есть список элементов, на который надо циклом назначить один обработчик, то здесь ваше решение не поможет.
Как правильно добавить обработчик (и вожможно ли такое) так чтоб при нажатии кнопки "Дальше" На сервер отправлялась информация не раз, а три раза с интервалом в одну секунду (с задержкой)!
Вот я только одного не могу понять:
какой толк в attachEvent и addEventListener, если все всеравно все они выполняются по одному событию? Ну напишу я 10 раз attachEvent, перечислив 10 разных функций. И что? Где это пригодится на практике? Проще объявить onclick, адрес функции и в ней уже перечислить список тех 10 функций. Разве так не проще?
На практике одно и тоже. Я не вижу ВООБЩЕ никаких плючов у attachEvent, за исключением примера с iframe
Скачал ты чей-то скрипт, а он ставит обработчик через elem.on(событие). И убил все твои обработчики на это событие.
разовый обработчик не всегда есть возможность написать. Ибо элемент может не существовать, а появляться в результете каких-либо действий пользователя. Тут и поможет создание такого обработчика.
И в правду, зачем вешать onclick'и через addEventListener и attachEvent, эсли
можно сделать проще:
И тем более, attachEvent нестабильно работает в Опере и IE.
у меня по кнопке addEventListener выдаются алерты с 1 по 7 на FF.
это чей-то глюк или опечатка?
Видимо это можно отнести к недостутку этого способа - когда алертишь 5 раз он алертится 7 раз :-))))
ps: если открыть исходник страницы, то можно увидить
Исходники страниц браузер делает сам, поэтому не верь ему.
Если на сайте при входе будет работать сценарий, который выводит "Привет (Ваш ник(Допустим proVIDec))!", то при просмотре исходного кода браузер даст не php скрипт, а текст "Превет proVIDec".
Браузер ничего с исходниками страниц не делает. Он рендерит то, что отдаст сервер.
А обработкой php скриптов (как и любых других server-side'овых) как раз занимается сервер.
Впрочем, это легко обойти при помощи небольшого замыкания, корректно передающего указатель this:
А вот так
передать получится?
Третий параметр в addEventListener совсем не понятен Что за "фаза погружения"?
Этот параметр объяснялся в главе введение в события:
Установка по стандарту W3C
Решение W3C работает во всех современных браузерах, кроме Internet Explorer.
Установка обработчика:element.addEventListener( имя_события, обработчик, фаза)
Удаление обработчика:element.removeEventListener( имя_события, обработчик, фаза)
Еще одно отличие от решения Microsoft это третий параметр – фаза.
Если он установлен в true, то при срабатывании события во вложенном элементе, обработчик будет вызван на фазе "перехвата", а если значение будет false, то - на фазе "всплывания". Подробнее об этом будет написано далее, в разделе этой статьи "Порядок срабатывания событий".
Немного дополню данный пост. Зачастую в функцию требуется передать некоторые параметры. Как вариант, можно расплодить глобальные переменные или создать один глобальный массив, из которого и вытягивать нужные значения. А можно решить данный вопрос и другим способом. Приведу свою функцию:
В данной функции генерится код двух других функций с подстановкой значений необходимых параметров в текстовом виде, после чего он прогоняется через eval - в результате мы имеем две функции select_region и select_city со всеми параметрами, которые им требовалось передать.
Плохое решение. Лучше сделать это с использованием замыкания.
Придётся делать свой луна-парк.. Всем одна функция, в функции лист обработчиков. В принципе если сесть и подумать то легко, только как не дать убить никогда свой универсальный on<событие>?
Вот только не всегда знаешь, какой это "divElem". А если есть список элементов, на который надо циклом назначить один обработчик, то здесь ваше решение не поможет.
Где можно найти имена всех событий?
Узнал про Greasemonkey. Тренируюсь. Почему-то нижеследующий скрипт работает практически всюду, кроме "e.mail.ru", подскажите почему?
window.addEventListener('load',function(e){
alert('alert [10-33-12]');
},true);
"Особенности addEventListener
Решение W3C работает во всех современных браузерах, кроме Internet Explorer."
Работает в IE 9 >
Только что проверил в IE 11 - все ок
Подскажите пожалуста кто нибуть!
Имеем опредиленый код формы:
Как правильно добавить обработчик (и вожможно ли такое) так чтоб при нажатии кнопки "Дальше" На сервер отправлялась информация не раз, а три раза с интервалом в одну секунду (с задержкой)!
Или скажу по проще:
Можна продублировать как-то отправку формы, от нажатия только одногораза на кнопку!?
Вот это то, что надо!
Этот материал предоставляет полезное объяснение о слушателях событий в JavaScript и том, как их использовать. Мне понравилось.