Почему JSLint ограничивает использование обработчиков событий HTML?

Question

При использовании значений по умолчанию «Good Parts» в JSLint использование обработчиков событий HTML (таких как onclick) не допускается.

Какая логика стоит за этим?Что в них плохого, чего следует избегать?

Answer 1

При использовании значений по умолчанию "Good Parts" в JSLint использование обработчиков событий HTML (таких как onclick) не допускается.

Использование обработчиков событий в фактической разметке помечено, да:

<div onclick="...">

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

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

<div onclick="if (a&lt;b) this.innerHTML= &quot;I said \&quot;Hello &amp;amp; welcome!\&quot;&quot;">

Естественно, трудно получить правильную кодировку, и если вы работаете с динамическими значениями, неправильная комбинация кодировок оставляет вас с проблемой внедрения скрипта (XSS).

То же самое в автономном скрипте:

somediv.onclick= function() {
    if (a<b)
        this.innerHTML= "I said \"Hello &amp; welcome!\"";
};

- один прояснившийся уровень прохождения.

JSLint не жалуется на это использование. Хотя некоторые утверждают, что использование слушателей лучше, так как вы можете добавить несколько слушателей к событию, это более тяжелое решение, так как вам нужно работать с IE <9 <code>attachEvent вместо addEventListener и, возможно, предоставить что-то для более старых браузеры, которые не поддерживают ни один.

Answer 2

Логика лучше всего описана фразой «разделение интересов» , которая является общим принципом разработки программного обеспечения. В этом случае наличие встроенного обработчика событий в HTML приводит к поведенческой проблеме (обработчику событий) в вашей презентации (HTML). Для некоторых древних советов см. Ненавязчивый DHTML и мощь неупорядоченных списков . Другими хорошими источниками являются A List Apart и, конечно, Wikipedia .

Answer 3

С ними все в порядке. Тем не менее, вы можете подключить только один слушатель с помощью этого метода (в отличие от использования addEventListener / attachEvent, которые позволяют несколько слушателей). Однако это не может быть проблемой для простого приложения.

Другая проблема заключается в том, что если вы используете атрибуты обработчика событий в своем HTML, вы смешиваете контент с поведением. Это не идеально, и ненавязчивая толпа JavaScript будет настаивать на том, чтобы вы это делали, но, опять же, достижение этого разделения - не единственное соображение, и для очень простого приложения я бы предпочел этот метод за его простоту. Существует также особенность атрибутов обработчика событий, которой нет у любого другого механизма, а именно то, что поведение JavaScript доступно сразу после рендеринга элемента, а не после загрузки документа (обычное время, которое вы в противном случае назначали бы обработчик события).

Answer 4

Я думаю, причина в следующем:

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

Возможно, он уже определен (с помощью атрибута onclick), и при его повторном определении в коде JS исходный обработчик теряется, что может привести к нарушению функциональности.Этого не произойдет, если вы выберете маршрут «добавить обработчик событий» (например, через jQuery's bind()).

Для небольшого веб-приложения, которое вы полностью контролируете, это может быть хорошо.Если код JS, который вы пишете, является плагином / библиотекой какого-либо рода, такое поведение становится неприемлемым.