Here is a simple example:
<a href="#" onclick="doSomething(); return false;">click this link</a>
If you did this once, it wasn’t such a big deal. But when multiple events were added to the DOM, this slowly became a nightmare for maintenance and page bloat, and so this method has mostly been done away with.
But, in my opinion, the maintenance issue is still complicated somewhat due to the fact that there is (apparently) no easy way to find out what behaviours occur on what elements.
Let me show you a simple example. Here’s the HTML:
<a href="#" id="myLink">click this link</a>
When you click the above link, any number of things could happen. Maybe it opens a modular window, maybe it causes something to slide up or slide down, maybe some content appears, or maybe an Ajax-based event is called. You’ll only know what happens if you click the link. But where does the event come from? Since we have no inline function call, how can we find out where the code is located?
How Do You Track Down the Code?
And this process becomes even more complicated if the element is targeted through the id of a parent element, or through an element type selector.
Does Firebug Help Us?
This process would especially be complicated if there were multiple behaviours on the same page, multiple scripts being loaded, and if jQuery or another library was thrown into the mix.
Someone on Twitter suggested using the “Break on…” features in Firebug. Those options are available when you right-click an element inside the HTML inspector. I couldn’t figure out how to use those features to identify the event, file name, or line number. I’d be glad to hear if someone is able to use that feature to track down the code that fires an event.
Additionally, some solutions have been proposed on Stack Overflow, but many of them are somewhat complicated and seem to be more time consuming than should be necessary.
A Nice Bookmarklet That Solves Part of the Problem
As you can see from the above screenshot, when the bookmarklet is triggered, the page is overlaid with some semi-transparent elements to indicate where the events take place. If you hover over any of the blue visuals, the code that fires the selected event appears in an another overlay. This is great, and can help us more quickly to figure out where to find the associated event.
A Possible (But Tedious) Solution
I have a very simple solution that allows the developer to be able to see immediately from viewing the HTML (whether in a DOM viewer or just by viewing the source) where to find the behaviour for that element:
<a href="#" id="myLink">click this link</a> <!-- JS: scripts/link.js line 34 -->
In many cases, it would not be very practical to include all those details. There might be new code added to the file that changes the line number, or the file itself might be merged with another file. So, you obviously don’t want to have to change all your JS “comment hints” whenever you make modifications to your code. So maybe this solution without the line number would work better:
<a href="#" id="myLink">click this link</a> <!-- JS: scripts/link.js selector: myLink -->
Now the code tells you that there’s definitely a JS event occurring here, and where to find it. I’ve also included a selector name that indicates how the element is targeted in the JS file. So while the bookmarklet shown above tells you an event is present, and gives you the code, this solution tells you what file to look in. I think the two methods combined improve the ability to find events over what may or may not be possible with Firebug.
What About Dynamic Comment Injection?
Thus, the HTML would be clean and the comments would still be viewable through the generated source. This could work quite well, and would prevent any changes in the code from altering the comment, because the comment info will be injected based on where the event is actually located.
How Do You Find Events in Foreign Code?
Does anyone have a better and easy-to-use solution? I’d love to hear your thoughts on this.