McArthur GFX

If you use a library that mimics classical inheritance into Javascript, like Prototype or Mootools, then you use the new Element() expression aplenty. It feels far nice to do it all in one constructor-like call, then using document.createElement , and then node.setAttribute and so forth a bunch of times. But I'm not going to argue which is more proper. Instead, what I've found is an annoying inconsistency with Internet Explorer 7 (probably 6 as well, but I didn't bother to check the obvious) when specifying the onclick attribute .

First, what I do that causes the problem.

var btn = new Element('a')

And of course, I include an object for the secord parameter that sets all the attributes of the element as well.

var btn = new Element('a',{
    'class':'deleteButton',
    'href':'/categories/delete',
    'text':'Delete',
    'onclick':'deleteCat(this); return false'
});
//creates <a href="/categories/delete" class="deleteButton" onclick="deleteCat(this); return false">Delete</a>
    

As you can see, very useful, very logical, very easy.

I did exactly this when you clicked on a New Category button; a little modal box showed up, you type in the name, and then the new category shows up in the list. And all categories have a button to delete said category. Since this was a new element in the DOM, any event listeners on deleteButtons wouldn't register for this new one.

There are three ways of handling this: one being to create a new event listener for each new button as it's created, two is to use event delegation and listen instead on a higher element for events on anchor tags, or three to specify an onclick function. I opted for the third option, regardless of which is best , because in my situation, all were equal in accessibility (my application requires Javascript), but the third is easiest. It seemed.

As Expected

Firefox did exactly what I wanted. New button, when clicked fires its onclick function. And, as should be expected, Internet Explorer did not. After the mandatory cursing ritual , I opened IE Developer Toolbar and inspected the newly created button. Of course, Mootools hadn't let me down. The element indeed had the onclick attribute, properly set to the function I wanted.

Curious if it was the way Mootools created the Element that broke it, I used the DOM methods in a test, first createElement('a'), then setAttribute('onclick','doStuff(this); return false'), and, look! Still broken .

This tells me then that Internet Explorer does not pay attention to onEvent attributes after the first DOM initialization . Now, messing with that attribute does nothing.  It doesn't set an actual event listener, so instead you must do so specifically on the Element in the Javascript.  Here's the final mess:

var dButton = new Element('a',{'class':'deleteButton',href:'/categories/delete',onclick:'deleteCat(this); return false',title:'Delete Category'});
//ie7 sucks
dButton.onclick = function() { deleteCat(this); return false; };
    

Should this be in the framework?

In retrospect, should fixing this be always up to myself everytime I do something similar, keeping IE's faults in mind? Or should the library I'm using (Prototype, Mootools) have this in mind in it's Element() function?

The function could have added to a check for the Trident engine, and if true, check for onEvent attributes. If true, set those attributes explicitly.

Seems like the better solution, so a developer can write a command and expect it to work cross-browser . Do you agree?