Javascript/DOM 事件命名约定

Javascript/DOM event name convention

提问by roy riojas

When I started doing web development, I realized Javascript event names were all in lower case with no separators, i.e. "mousedown", "mouseup", etc. And when working with the jQuery UI library, I noticed they also use the same convention; i.e. "dropdeactivate"as in the following example

当我开始做 Web 开发时，我意识到 Javascript 事件名称都是小写的，没有分隔符，即"mousedown"、"mouseup"等。在使用 jQuery UI 库时，我注意到它们也使用相同的约定；即“dropdeactivate”，如下例所示

$( ".selector" ).on( "dropdeactivate", function( event, ui ) {} )

While this works well for names that are only 2 or 3 words, it is really awful for names with more words on it.

虽然这对于只有 2 或 3 个单词的名字很有效，但对于包含更多单词的名字来说真的很糟糕。

Despite of this I followed that convention too when I have to fire custom (synthetic) events that I created, until recently when I decided it was better to start using some form of separator. Now I use something like "drop:deactivate", or "app:ready".

尽管如此，当我必须触发我创建的自定义（合成）事件时，我也遵循了该约定，直到最近我决定最好开始使用某种形式的分隔符。现在我使用诸如"drop:deactivate"或"app:ready" 之类的东西。

on iOS apple recently added this event for the HTML 5 Airplay API, and I agree with the autor of this post http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-reviewwhen he says:

在 iOS 上，苹果最近为 HTML 5 Airplay API 添加了这个事件，我同意这篇文章的作者http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review当他说：

I think "webkitcurrentplaybacktargetiswirelesschanged"has won the record: the longest JavaScript event name ever.

我认为“webkitcurrentplaybacktargetiswirelesschanged”赢得了记录：有史以来最长的 JavaScript 事件名称。

What is the reason behind this weird convention?why not use any form of separator or camelCase convention to name the events in a more readable way?

这个奇怪的约定背后的原因是什么？为什么不使用任何形式的分隔符或驼峰命名法以更易读的方式命名事件？

I think there is a reason for that, lot of clever people worked on this... But after a while I'm still wondering why?

我认为这是有原因的，很多聪明的人都在做这件事……但过了一段时间我仍然想知道为什么？

采纳答案by raina77ow

Unfortunately, it's not so simple when you deal with legacy conventions. And DOM Events have a lot of history behind them.

不幸的是，当您处理遗留约定时，事情就没有那么简单了。DOM 事件背后有很多历史。

Here's how type attribute of Eventis defined in DOM2 Events specification:

以下是 DOM2 Events 规范中Event的 type 属性是如何定义的：

Interface Event (introduced in DOM Level 2)
type(of type DOMString, readonly)

The name of the event (case-insensitive). The name must be an XML name.

接口事件（在 DOM Level 2 中引入）
类型（DOMString 类型，只读）

事件的名称（不区分大小写）。该名称必须是 XML 名称。

The reasoning behind this, I suppose, is explained by this paragraph in the same doc:

我想这背后的原因在同一个文档中的这一段中解释过：

In HTML 4.0, event listeners were specified as attributes of an element.[...] In order to achieve compatibility with HTML 4.0, implementors may view the setting of attributes which represent event handlers as the creation and registration of an EventListener on the EventTarget.

在 HTML 4.0 中，事件侦听器被指定为元素的属性。[...] 为了实现与 HTML 4.0 的兼容性，实现者可以将表示事件处理程序的属性设置视为在 EventTarget 上创建和注册 EventListener .

Now, while the stance has changed in DOM3 (where event names are case-sensitive), the original approach is, I suppose, ofter considered to be the safest bet - so one won't have to depend on user agents' correctness (check this discussionand this funny issueas examples).

现在，虽然 DOM3 中的立场发生了变化（事件名称区分大小写），但我认为最初的方法通常被认为是最安全的选择 - 所以人们不必依赖于用户代理的正确性（检查这个讨论和这个有趣的问题作为例子）。

Note that W3C itself has registered a whole slew of PascalCased events in DOM2 (all the MutationEvents, DOMActivate, DOMFocusInand DOMFocusOut).

请注意，W3C 本身已经在 DOM2 中注册了大量 PascalCased 事件（所有 MutationEvents DOMActivate、DOMFocusIn和DOMFocusOut）。

回答by m59

As far as I can tell, there is no official practice regarding that subject. It seems to me that since camelCase is the generally accepted standard for names in js, that the same would apply with event naming. However, as you noted, js itself and many libraries do otherwise. I have seen both conventions used by great programmers, so I believe it is simply inconsequential. In the case of "the longest JavaScript event name ever" that's a great example of an event that should have used camelCase, in my opinion...or maybe they could have just shortened it :)

据我所知，没有关于该主题的官方实践。在我看来，由于驼峰命名法是 js 中普遍接受的名称标准，这同样适用于事件命名。但是，正如您所指出的，js 本身和许多库并非如此。我见过伟大的程序员使用的两种约定，所以我认为这根本无关紧要。在“有史以来最长的 JavaScript 事件名称”的情况下，这是一个应该使用驼峰命名的事件的一个很好的例子，在我看来……或者他们可以缩短它:)

If you want to stick to what you've seen more often, use lowercase. If you think that's hard on the eyes (I do), use camelCase. I probably wouldn't use anything else if you're trying to conform to a standard.

如果您想坚持经常看到的内容，请使用小写字母。如果您认为这对眼睛不好（我认为），请使用驼峰式命名法。如果您试图符合标准，我可能不会使用其他任何东西。

回答by Labib Ismaiel

when it comes to conventions, it is in a way or another, a habit, JavaScript frameworks seem to follow the convention of the JavaScript DOM event API, I don't know if there is a reason or at least a clear reasoning why, but it just is. for general conventions, crockfordis one of the best references there is, but there is no mentioning for event naming, but at the same time herethe events seem to be a little different, which made me think of it as a matter of choice, no more, no less

说到约定，以某种方式，一种习惯，JavaScript 框架似乎遵循 JavaScript DOM 事件 API 的约定，我不知道是否有原因或至少有明确的理由，但是就是这样。对于一般惯例，crockford是最好的参考之一，但没有提到事件命名，但同时这里的事件似乎有点不同，这让我觉得这是一个选择问题，不多也不少

回答by Tamb

I like how Bootstrap works: hidden.bs.modal

我喜欢 Bootstrap 的工作方式： hidden.bs.modal

HOWEVER: As mentioned in @raina77ow 's answer, you should follow the DOM2 spec.

但是：正如@raina77ow 的回答中提到的，您应该遵循 DOM2 规范。

The spec mentions following XML naming guidelines: https://www.w3.org/TR/1998/REC-xml-19980210#NT-Name

该规范提到了以下 XML 命名指南：https: //www.w3.org/TR/1998/REC-xml-19980210#NT-Name

From what I've gathered:

从我收集到的：

• use lowercase if possible
• you can use any of these characters to help namespace . - _ :
• I would use any of these. probably like this apporlibraryname:componentname.eventtype

• 如果可能，请使用小写
• 您可以使用这些字符中的任何一个来帮助命名空间 . - _ :
• 我会使用其中任何一个。大概是这样apporlibraryname:componentname.eventtype

My reasoning for his is because sometimes you have separate apps or libraries that could be completely independent widgets. At a glance it's easy to identify where this thing event lives with a :The component precedes a .because most components are written as objects.

我对他的推理是因为有时你有单独的应用程序或库，它们可能是完全独立的小部件。一目了然，很容易通过 a 确定该事物事件所在的位置。:该组件位于 a 之前，.因为大多数组件都是作为对象编写的。