javascript - 事件 - 在哪里放置它们？答案

【问题标题】：javascript - events - where to place them?javascript - 事件 - 在哪里放置它们？
【发布时间】：2010-08-23 08:26:53
【问题描述】：

我希望在 js 开发者社区中我们可以就此达成共识：

我们应该在我们的 HTML 文档 inside 还是 outside 声明或 onclick、onkeyup... 等事件？

1) 我更喜欢将它们分开。真的。 2) 我也知道 HTML5 在游戏中添加了一些新的交互元素...

问候，内存

【问题讨论】：

标签： javascript events placement

【解决方案1】：

考虑阅读Unobtrusive JavaScript 和jQuery。

【讨论】：

【解决方案2】：

至少十年来，内联编写事件处理程序一直是一个非常糟糕的主意。

即使访问像“element.onkeyup”这样的属性也是一个非常糟糕的主意。

使用监听器。更好的框架。

编辑：这就是 Tim Down 的评论荒谬的原因：

如果任何编程决策的基本原理都是以“如果您知道您只需要...”开头，那么不要这样做。严重地。
“所有可编写脚本的浏览器”实际上是指 IE5.5+ FF2+ Safari 3+ Opera 9+。这涵盖了 99% 以上的网络用户，并且所有这些浏览器都支持事件侦听器。与访问事件处理程序属性相比，事件侦听器具有主要优势 - 最大的优势是任何事件都可以有多个侦听器。在现代 Javascript 编程中，这种情况一直都在发生。仅仅因为你可以就使用过时的事件处理系统来特殊化你的代码是一个糟糕的想法，对真正好的想法怀有敌意，比如使用库和编写不显眼的、一致的代码。
return false; 是一种完全违反直觉和反语义的方式，表示“停止在 DOM 树上/下冒泡/传播此事件”。你知道什么是直觉吗？库代码中的常用表达式，例如 event.stop()。

【讨论】：

非常感谢听众的建议和框架一...我会尝试更多地了解事件监听器。
废话。如果您知道在element 上只需要一个事件处理程序，那么element.onkeyup 就是要走的路。首先，它适用于所有可编写脚本的浏览器，并且在所有浏览器中的工作方式完全相同（除了从哪里获取事件对象）。其次，防止事件默认行为的机制在所有浏览器中都是简单的return false;。
知道了。好吧，事实是，我只需要一个。但我是一个愚蠢的慢程序员，希望尽可能地扎实，程序员。一天。 :) 这就是为什么我在具有 100 条或更少记录的数据库上使用 PDO 的原因。哦，好吧……但是，有时，我们需要完成它，我只是希望，当那一天到达 js 方面时，我可以说：“是的，我将立即编写一个 js 侦听器”； ) 但为了做到这一点……我相信，我们真的需要受苦。这就是我所知道的。 :) K. 问候。 :)
MEM：对不起。我的“废话”。过于激进并针对三联画。
三联画： 1. 什么？这种笼统的说法是过度设计而不做任何事情的秘诀。如果不首先定义您的要求，您将无法做任何事情。 2. 我不太理解您关于特定浏览器的观点。我的是支持事件处理程序属性的浏览器比支持 addEventListener/attachEvent 的浏览器更多。如果您的浏览器不支持侦听器现在在很大程度上无关紧要，那么我同意这一点。此外，“过时”并不意味着不好。 3.return false不代表你说的。这意味着“不执行默认浏览器操作”。

【解决方案3】：

理想情况下，如果您可以定义事件代码并将这些事件附加到单独 JS 文件中的匹配元素。尽可能分离 JS 和 HTML。

【讨论】：

@ALL - 新来的 html5 怎么样。我们能不能做同样的事情。 Html5 有新的事件可玩，不是吗？我想知道我们是否也可以在那里使用那种技术......在这背后，我看到我不清楚这些事件的性质，它们属于 DOM 核心，或者它们属于 javascript 核心不是吗？
我无法预见 HTML5 会改变保持 JS 代码和 HTML 分离的建议 - 希望人们能找到更好、更清晰的方法。
@MEM：HTML5 没有任何改变。你有新的活动，但做法是一样的。
这里我有这样的关系：想要动态检查或修改网页的 JavaScript 脚本需要 DOM。换句话说，文档对象模型是 JavaScript 查看其包含的 HTML 页面和浏览器状态的方式。

【解决方案4】：

当前流行的观点是一切都必须不显眼，这意味着someElement.onclick = function(e) { ... }; 等事件处理程序属性被广泛反对，<input type="button" onclick="doSomething()"> 等事件处理程序属性被彻底摒弃。事实上，两者都有有效的用途。

将行为（例如脚本化事件处理程序）与内容分开的愿望是很自然的，也是主要考虑因素，但不应是唯一考虑因素。如下总结所示，创建事件处理程序的三种方法各有优缺点，在特定情况下，行为和内容的分离可能不是最重要的问题。

总之，对于给定的任务，请使用适合您需求的最简单的方法。

事件处理程序属性

示例

myElement.onclick = function(e) { alert("Clicked"); };

这些对于将事件处理程序分配给您在脚本中创建的元素特别有用，并且肯定只需要一个侦听器。

优势

将行为与内容分开
适用于所有可编写脚本的浏览器
在所有浏览器中都一样，除了 Event 对象来自哪里的问题（IE 中的window.event，其他浏览器中的函数参数）
使用return false 防止默认浏览器行为的普遍支持方法

缺点

只允许一个特定对象和事件的侦听器
在 HTML 源代码中的元素上，通常在加载文档之前不会分配处理程序

事件处理程序属性

示例

<input type="button" value="test" onclick="alert('Clicked');">

当元素在文档完成加载之前响应事件很重要时，这是唯一有效的方法（请参阅 http://peter.michaux.ca/articles/the-window-onload-problem-still 对此进行更长时间的讨论）。此外，这是添加事件处理程序的最简单方法。

优势

适用于所有可编写脚本的浏览器
在所有浏览器中都一样
元素一渲染就可以工作
添加事件处理程序的最简单方法
使用return false 防止默认浏览器行为的普遍支持方法
在一个非常简单的页面上，这是最易读的方法
Standardized in the HTML 4 spec

缺点

将行为与内容混合在一起
只允许一个特定对象和事件的侦听器

addEventListener/attachEvent

示例（未显示attachEvent 等效项）

myElement.addEventListener("click", function(e) { alert("Clicked"); }, false);

这是唯一允许您将多个侦听器附加到特定对象上的特定事件的方法。 addEventListener 在 DOM Level 2 Events specification 中标准化。

优势

将行为与内容分开
允许多个事件监听器
addEventListener 是一个现代标准，在 IE 9 中得到支持，这意味着当前所有主流浏览器都将在 IE 9 发布时支持

缺点

正确实现跨浏览器有点复杂
IE 的attachEvent 不完全等同于addEventListener
在 HTML 源代码中的元素上，通常在加载文档之前不会分配处理程序

【讨论】：

+1 顺便说一句，当您说 addEventListener/attachEvent 跨浏览器正确实现很复杂时，这不是真的，这可能是因为人们已经习惯使用甚至不使用的 JS 库知道它有多简单，看看stackoverflow.com/questions/2631241/…，告诉我你的想法。
Marco：我之前写过跨浏览器的 addEventListener/attachEvent 包装器，我同意这并不难，但有一些问题不是很明显，例如问题this 的监听器函数以及如何将 Event 对象传递给监听器函数。两者都很容易解决，但您需要了解它们。