Enter the MooTools

While the original version used jQuery (1.2.6 at that time) and lots of people like it, we (mootoolers) have a different approach to code specially emphasizing on OOP techniques and readability. Part of the issue might not be jQuery per-se and be Dave's code that was a little obfuscated, but it anyways has a lot of room for improvement.
This article will just describe differences between the MooTools implementation and the Dave's jQuery one, so unless stated otherwise, everything from the ALA article applies here.

enter the Sprites2 class

Part of the requirements I imposed myself when porting to MooTools was that it had to be easier to use than the jQuery version, and that it should give a certain degree of flexibility to extend the possible transition effects.
End result is a class intuitively named Sprites2, where you gracefully pass named parameters:

1

new Sprites2({mode: 'fade', item_selector: 'ul.nav a', duration: 250});

changes to original code and idea

Apart from moving the code to a class, a change to note is the removal of the :active state from the CSS and the setActive parameter in the JS code. This was mostly a personal preference as the :active pseudo-class created a few issues when holding the mouse on the element and releasing outside of it. Other notable changes in the CSS are the simplification of the implementation/adaptation process by using a simpler approach on the styles (for example, using height:100%; where applicable instead of redefining height:48px; 5 times in the CSS).

MooTools also has a free "upgrade" built-in: animations have an internal state so that if you roll out from the element and enter it again, the transition will continue to run smoothly. In contrast, jQuery version (may be by code design, maybe because of a library limitation) flickers madly when you roll over and out of the element repeatedly with an interval less than the effect duration.

Also to note, and as mentioned, the Sprites2 class can be easily extended outside of the sprites2.js file with just a few lines of code to create for example a horizontal slide effect:

1
2
3
4
5
6
7
8
9
10

Sprites2.implement({
  effects: {
    slide_x: function(fx_element) {
      fx_element.store('width', fx_element.getSize().x).setStyles({'width': 0});
 
      this.show_fn = function(fx_element) { fx_element.tween('width', fx_element.retrieve('width')); };
      this.hide_fn = function(fx_element) { fx_element.tween('width', 0); };
    }
  }
});

and you can start using it right away with new Sprites2({mode: 'slide_x'});. This obviously works any way you want, as you can manually add or remove the effects directly in the source file.

download, full demo and requirements

The example here is running on a standard google hosted version of mootools 1.2.1. For those of you that use custom builds, just be sure to add FX.Tween and FX.Morph to your standard array of includes (morph is only used by the "animate" effect, so if you don't use that one you can exclude it.)

View full online demo

Download Sprites2 for MooTools [zip].

new! – by popular demand (not really), I have just set-up a git repo so you can fork the latest source: http://github.com/gonchuki/sprites2-moo

License: Creative Commons Attribution-Share Alike 3.0
disclaimer: original code did not contain any license whatsoever (like all ALA code), so I assumed a CC share-alike license applies perfectly in this case.
]]> http://blog.gonchuki.com/archives/css-sprites2-its-mootools-time/feed/ 24 http://blog.gonchuki.com/archives/the-web-is-event-driven-and-so-is-your-code/ http://blog.gonchuki.com/archives/the-web-is-event-driven-and-so-is-your-code/#comments Fri, 03 Aug 2007 05:08:52 +0000 gonchuki http://blog.gonchuki.com/archives/the-web-is-event-driven-and-so-is-your-code/ You click on something and then something else happens, you scroll the window and something moves around.
Welcome to the event-driven web, a concept that still some developers fail to assimilate.

the event-driven web

Developers need to understand that events are (or should be) everywhere, whether on DOM elements, over the HTTP protocol on in plain old javascript objects.
Now, the former two methods are well agreed and documented, yet the later is still an undiscovered world for many developers.

event driven… objects?

Think about it, you attach events to DOM elements, you respond to events pushed by the server yet you are still using a rigid callback based architecture in your objects and pseudo-Classes. That's plain wrong.
let's take object foo as:

1
2
3
4
5

var foo = {
  bar: function(baz) {
    /* do some stuff here */
  }
}

what the average developer does when they need to do something after bar is finished is to add another parameter into the call of bar:

1
2
3
4
5
6

var foo = {
  bar: function(baz, callback) {
    /* do some stuff here */
    callback();
  }
}

If you then need another callback to do something in the middle of bar, soon enough before you notice you will be growing a bloated piece of code. You will notice this approach is not extensible any more when you see you need *yet another* parameter passed into your object to add the new functionality.
To keep things clear, what your object/widget/Class should do is to "raise it's hand" when it needs our attention, and allow us to externally do whatever we desire on the outside, we should not pass-in callbacks to the object, we should run our callbacks once the object told us it's proper time to do so.

mootools to the rescue

So yes, achieving this in plain javascript is not possible as events are only part of the DOM elements. However there's one nifty (yet barely known) feature in mootools that lets us extend any object with whatever set of functions we desire. For the Ruby folks, that's mixins for javascript.

If you are a mootools lover, you may already know that Classes natively implement the Events interface. What you might not know is that *any* object can be mixed-in with Events to be that event-raiser we need.
So when needing to set-up callbacks in our code we could better use:

1
2
3
4
5
6
7

var foo = {
  bar: function(baz) {
    /* do some stuff here */
    this.fireEvent('onComplete');
  }
}
$extend(foo, new Events);

The result of this is that our object foo can now raise events, ones that we can attach to at *any* point of our code by the simple means of:

1
2
3

foo.addEvent('onComplete', function(){
  alert("hello from foo's onComplete");
}.bind(this));

and any time you need a new callback you can just set up another event and respond to it accordingly. Setting up an event of course, is as simple as adding a new fireEvent call where necessary and no more fiddling around with you perfectly built object.

conclusion

Events are everywhere on web development, and it's our job to use them where applicable and know how to do it. Events for regular objects help you keep your code extensible and semantically consistent with the rest of your DOM-based code, and that is a Good Thing.

PS: for those out there not using mootools or not needing it's whole range of functionalities, there's also the tiny Object.Event library that basically allows you to reach the same results, with a prototype-like syntax.

2008-07-13 Update: Having re-read this article many times, I must warn you that I do not fully agree any more to many of the points exposed at that time, so take the lecture with a grain of salt and simply imagine that the article was correctly written and explained.
Still, there's a lot of potential in using custom events inside your javascript code and I encourage you to investigate more into the topic.