Adding Events to Adding Events in MooTools

One of my huge web peeves is when an element has click events attached to it but the element doesn't sport the "pointer" cursor. I mean how the hell is the user supposed to know they can/should click on something? It's insane. I've called Chris Coyier out on it, fellow developers out on it, and hell -- I'd call my mother out on it if I had to.

I set out to find a method to automatically give the pointer cursor to elements that get a "click" event attached to them. Essentially, I wanted to add an event to adding an event. Fortunately MooTools makes this possible.

CSS animations aren't just for basic fades or sliding elements anymore -- CSS animations are capable of much more. I've showed you how you can create an exploding logo (applied with JavaScript, but all animation is CSS), an animated Photo Stack, a sweet...

I remember the early days of JavaScript where you needed a simple function for just about everything because the browser vendors implemented features differently, and not just edge features, basic features, like addEventListener and attachEvent. Times have changed but there are still a few functions each developer should...

The hottest device out there right now seems to be the iPad. iPad this, iPad that, iPod your mom. I'm underwhelmed with the device but that doesn't mean I shouldn't try to account for such devices on the websites I create. In Apple's...

A week back I saw a great effect created by CSSKarma: input labels being animated horizontally. The idea is everything positive: elegant, practical, unobtrusive, and requires very little jQuery code. Luckily the effect doesn't require much MooTools code either!
The HTML
A...

Fantastic! When I tried this, it worked perfectly except that I have some code that adds a ‘click’ event handler to the document when a popup opens so that it closes if the user clicks outside the popup and document.setStyle doesn’t exist – so I added if (this.setStyle) {} around the code to make it work for me.

Иван

(I like the idea very much. It’s just some thought I have on it.)

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.

Patrick

Hey David, really liked that small example for the expandability in mootools.

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:

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!

@Patrick: I’ve the error that you explained on Internet Explorer 8 but I don’t understand how I can solve it.

Patrick

Alright here’s some things I noticed, that every MooTools developer should keep in mind (these things were connected to my issues above..):

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

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