Your adding cursor pointer to, for example an entire list or the parent UL, instead of the list elements LI.

I have one app that uses a click event on the body of the document and delegates the events depending on what div you clicked. So the entire document now has a pointer cursor.

So be warned if you use Delegation techniques.

Don’t use names for input fields that might’ve been reserved by mootools already – e.g. “send”!
Explanation: Mootools adds a method “send()” to elements (used with Request) – lots of people like to give their <input type=”submit” /> an additional name, so that they can check for a submitted form in php (if (!empty($_POST["send"]))…) – now “send” is already taken by mootools, giving this input another property named “send” would require an overwrite of an element property, which IE (no matter which version) will respond to with an “The Object doesn’t support…” error – should be fixed in MooTools 2.0 but for now, simply avoid names or properties with “reserved” names (e.g. use “sent” instead).
Here’s what I came up with for the “adding link-cursor for clickable elements”-trick (works without errors in any IE so far):

/* update cursor on add/remove click event */
Element.Events.click = {

Element.Events.click = {
base:’click’,
onAdd: function() {
if(this.getStyle && this.get(“tag”) != “a” && !this.match(“input[type=text]“) && !this.match(“input[type=password]“)) {
this.store(‘original-cursor’,this.getStyle(‘cursor’));
this.setStyle(‘cursor’,'pointer’);
}
},
onRemove: function() {
if(this.setStyle && this.get(“tag”) != “a” && !this.match(“input[type=text]“) && !this.match(“input[type=password]“)) {
this.setStyle(‘cursor’,this.retrieve(‘original-cursor’));
}
}

};

It’s still rough (the selector could be refined that makes sure that this style-switching only occurs on elements which aren’t links already or aren’t neither an input-element containing text or an input-element containing a password value (which should show a textinput cursor).

Somehow (don’t ask me why), this.setStyle (which results in setComputedStyle in IE), won’t work in IE correctly when adding Events to Events, “getStyle” however worked…

Using a similar bunch of code in a commercial project led to 3 hours of JS-debugging here however – let me explain:

I extended the click-Event in the same way you did, but added an additional check for the tagname of the element (don’t need to add a click-cursor, if the element in question is an <a>-element (when using makeResizable on such an element, you’ll lose the resize-cursor if you don’t fix this).

Everything went fine in Firefox and Webkit, but in IE8 it all fell apart. I’m still trying to find out, what combination of code let to this error, but long story short:

IE8 halted JS-execution because of an error in the mootools-core.js – this line of code:

getComputedStyle: function(property){
if (this.currentStyle) return this.currentStyle[property.camelCase()];
var computed = this.getDocument().defaultView.getComputedStyle(this, null);
return (computed) ? computed.getPropertyValue([property.hyphenate()]) : null;
}, “);

As we all know, IE has some problems with getProperty and setProperty on elements that weren’t in the original DOM the server sent to the browser. Now as the bad boy that I am, I created my own mootools class for notification boxes. They can be dragged, resized, closed or they can be tooltops, little popups showing where something went wrong on the website with a litte arrowhead, you name it. Beautiful thing, just one class I could do all this stuff with.

This class is created before the DOM is loaded, but not instantiated (important difference) – two instances are then created when the domReady-event is fired. But somewhere between creating the instances and adding the event to the click-event, IE8 seems to crumble. If I’m moving your part of the code to the domReady-event, nothing changes, the only “fix”, was using an IE-browserdetection and hiding this particular piece of code from IE..

It’s as if IE is already firing the onAdd-event even though the DOM hasn’t been loaded yet (read: IE seems to evaluate the initialize()-method of my class before it’s even instantiated).

So nothing left to say but “Beware of IE!” – if you’d like to see the code that brought IE to its knees (even though it’s all working fine in every other browser), feel free to contact me!

I strongly believe that the design should appeal to the user for interaction — if something can be interacted (click, drag, resize — you name it) with, it should have the proper cursor set, regardless of whether the interaction came from progressive enhancement or not.

In the case of the front end getting the job right and the user still not being able to grasp where is the clickable area, the user is:

a) extremely dumb
b) born in the early 19th century and is currently worshiping the big (even bigger if it is a CRT) black box

However, one can never be sure (that the front end did job right) so this might come in handy.