Javascript/DOM event name convention

Question

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

$( ".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.

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".

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-review when he says:

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

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?

Answer 1

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

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

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.

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.

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 discussion and this funny issue as examples).

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

Answer 2

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 :)

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.

Answer 3

I like how Bootstrap works: hidden.bs.modal

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

The spec mentions following XML naming guidelines: 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

My reasoning for this 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.

UPDATE:

But you can do whatever. As long as it's consistent. It would be nice to have some open standards so libraries can have some level of congruence.

Maybe the above is the library-component namespace. Idk. But I would document your reasons as well. Any extra detail will help people consuming your app.

Answer 4

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, crockford is one of the best references there is, but there is no mentioning for event naming, but at the same time here the events seem to be a little different, which made me think of it as a matter of choice, no more, no less