views:

62

answers:

1

In order to add events we could use this simple 1st solution:

function AddEvent(html_element, event_name, event_function) 
{       
   if(html_element.attachEvent) //Internet Explorer
      html_element.attachEvent("on" + event_name, function() {event_function.call(html_element);}); 
   else if(html_element.addEventListener) //Firefox & company
      html_element.addEventListener(event_name, event_function, false); //don't need the 'call' trick because in FF everything already works in the right way          
} 

or this 2nd solution (that adds inline events):

function AddEvent(html_element, event_name, event_function) 
{       
   var old_event = html_element['on' + event_name];
   if(typeof old_event !== 'function')
      html_element['on' + event_name] = function() { event_function.call(html_element); };
   else
      html_element['on' + event_name] = function() { old_event(); event_function.call(html_element); };
}

These are both cross-browsers and can be used in this way:

AddEvent(document.getElementById('some_div_id'), 'click', function() 
{             
   alert(this.tagName); //shows 'DIV'
});  

Since I have the feeling attachEvent/addEventListener are used more around in events handling implementations, I'm wondering:

Are there any disadvantages/drawbacks against using the 2nd solution that I might better be aware of?

I can see two, but I'm interested in more (if any):

  1. the 2nd solution screws up innerHTML of elements by adding events inline
  2. Using 2nd solution I can easily remove all functions associated with a certain event type (html_element['on' + event_name] = null), but I can not use detachEvent/removeEventListener to remove exactly a specific function.

Any answers like: "use jQuery" or any other FW are pointless!

+1  A: 

With the 2nd solution, you have to manually call the previous functions, making it hard to remove specific listeners (which, to me, sounds like something you'd rather want than clearing all listeners), while on the second solution, you can only clear them all at the same time, unless you want to emulate the first functionality.

Personally, I always use the first solution, because it has the advantage of not having to worry about clearing possible other event listeners.

The mozilla wiki also lists the advantages that the first solution works on any DOM element, not just HTML elements, and that it allows finer grained control over the phase when the listener gets activated (capturing vs. bubbling) with the third argument.

yorick
I think you have the first thing and second thing backwards in your first 2 paragraphs.
Roatin Marth
@yorick: +1 i read link you suggested, but the three points explained by Mozilla site are not that true: "1. It allows adding more than a single handler for an event" true but with both functions I wrote in answer you can add more than a single event handler. "2. It gives you finer-grained control of the phase when the listener gets activated (capturing vs. bubbling)" true, but it's easy to add stopEvent function to prevent deafault and stop bubbling, moreover attachEvent does not have such beahvior so would anyayw have to create a cross-browser function.
Marco Demajo
@yorick: (continued) "3. It works on any DOM element, not just HTML elements.", interesting, but I don't see a real life example where I might need to add an event to a dom node which is not also an HTML element.
Marco Demajo
@Marco Demaio: 1. true. but your functions are non-native, and any other person who'd want to register an event, would clear out the entire onload.2. true3. SVG tags?
yorick