Setting Up

Picking up where we left off last time, I'm going to create the tooltip div, declare a couple variables, and then bind "mouseover," "mousemove," and "mouseout" all at once. In addition to $livetip and tipTitle, I'm declaring showTip (and leaving it undefined for the moment) and delay. The showTip variable will be used as a reference for the setTimeout function, and delay will be used to set the time after which the function within setTimeout's argument will execute (in this case, 300ms).

Of course, you don't have to use a variable for the delay, but I like to have that sort of setting up top where I can find it easily. Also, if I ever decide to convert this script into a plugin, having the delay stored in a variable will make it simpler to convert it to an option.

Setting the Timeout

Inside the .bind(), and after the business of determining whether the event is being triggered by a link or one of its descendants, the setTimeout is called on line 12:

setTimeout is actually a method of the window object; as such, the this keyword inside its function argument will refer to window. It's not of much concern here because, with event delegation, we're relying on event.target rather than this, but I thought it might be worth mentioning anyway.

Note that within the setTimeout function, I'm storing a little data (line 13) for the link to indicate that the tooltip is active on it. This tipActive information then determines what to do on mouseout.

Clearing the Timeout

On mouseout, if the link has the tipActive data, that data is removed (line 29, below), the tooltip is hidden (line 30), and the link's original title attribute value is restored if tipTitle has a value (line 31). If that tipActive data is not associated with the link, then the timeout that was set on mouseover is reset with clearTimeout (line 33).

The mousemove part hasn't changed from what it was in the previous post, except that it first checks if the "tipActive" data is assigned to the link. I figured that setting the top and left properties of the tooltip is probably more work than doing a little check on the link's data, so why bother setting them if I don't have to?

So, that's it. Just add a simple setTimeout delay and conditionally clear it. If you want to set a delay on mouseout, you can do that the same way.

Check out the demo or download the zip (or neither, if you're stubborn).

Flipping the Tip

Next time, I'll show how to flip the tooltip from the right side of the cursor to the left if it would otherwise get cut off by the edge of the browser window.

For review, here is the final version of the script from the last post:

Bind Multiple Events at One Time

As I mentioned last time, this repeats code where it really shouldn't. For example, lines 5, 19, and 24 all check that moused-over element (or one of its ancestors) is a link. One way to reduce the repetition is to bind all three events at the same time (line 4):

This modification relies on the type property of the event object, checking it to see which of the three event types were triggered and acting accordingly. That way, I can get away with writing the $link and link declarations and the link check one time instead of two or three.

Other changes

Here are a few other changes worth mentioning:

• Line 1 declares the $livetip variable while at the same time creating the tooltip div and appending it to the body. Now the script can refer to that variable rather than having to call $('#livetip') each time it is shown, moved, hidden, and so on.
• Rather than wrap nearly everything in an if block, I made the function return if there is no link selected. Some people have a philosophical problem with multiple return points in a function, and it can make it hard to decipher and debug code sometimes, but here I think it's okay.
• On "mouseout" (lines 23-28), the script is resetting link.title to tipTitle only if tipTitle has a value. This, I'm hoping, fixes the problem reported by Moritz Peters of the tooltip not displaying correctly if you first mouse over a link before the document is ready.

Try the demo or download the zip (or both).

Adding a Delay

Tomorrow—for realz this time—I'll show how to add a short delay on mouseover before showing the tooltip.

P.S. You see the "$" in "$liveTip" and "$link"? There is nothing special about that—no special meaning given to "$" in JavaScript. It's just a convention that some jQuery folks have adopted to remind ourselves that the variable is holding a jQuery object.

Event Delegation, Again

The key to having JavaScript handle hundreds, or even thousands, of elements on a page is to use event delegation. As Louis-Rémi Babé described in Working with Events, Part 3: More Event Delegation with jQuery, jQuery's .live() method makes event delegation dead easy. A simple tooltip script using .live() might look something like this:

This script does the following:

• Creates a single tooltip element that will be shown and hidden as the user mouses over links (line 1)
• Hides the tooltip and appends it to the body (line 1)
• Changes the tooltip's contents according to the moused-over link's title and href attributes (lines 7 and 14)
• Places the tooltip on the page 12px below and to the right of the cursor position at the time that it entered the link (lines 9–13)
• Shows the tooltip (line 15)
• Sets the link's title attribute to an empty string when the user mouses over the link; this prevents the browser's default tooltip from appearing (line 8)
• Sets the link's title back to what it was originally and hides the tooltip when the user mouses out of the link (lines 16–19)

A Little Style

At minimum, the tooltip needs to have the position: absolute style declaration for it to be positioned correctly on the page, but I threw in a little extra CSS to make it look more appealing:

Typically I like to include live demos directly in the blog entry, but since this one involves 2,000 links, I've set up separate demo pages. Check out the tooltip demo using .live(), or download the zip.

A Little Less Simple, A Little More Speedy

Using .live() in this way avoids binding event handlers directly to the thousands of links on the page. However, it doesn't prevent jQuery from searching the entire document for all of those links. After all, I'm still using the $('a') jQuery function. Also, at least for now, .live() binds events to document, forcing event bubbling all the way up the DOM each time. If there is a noticeable performance lag when the script is initially executed, it may help to use custom event delegation. For example, here I bind the events to a containing table element:

With this approach, I needed to first make sure I was dealing with a link before I tried to do anything with it. Line 5 uses the .closest() method to select the <a> that is either the event.target or one of its ancestors. Line 6 checks the length property to see if any elements are included in the variable declared in line 5.

Note the use of .bind() instead of .live() and event.target instead of this. I could have used the .mouseover() and .mouseout() shortcut methods, but since I used .live() in the first example, it was easier to simply replace "live" with "bind." Also, you may be wondering why I used mouseover / mouseout when I could have used mouseenter / mouseleave or even the .hover() method (which uses mouseenter and mouseleave internally). The reason is that mouseenter and mouseleave prevent the event bubbling that this script relies on for its event delegation. Those two events would be triggered only when the mouse enters or leaves the full table, while mouseover and mouseout are triggered whenever the mouse enters or leaves any of the table's descendant elements, as well.

View the demo using custom event delegation, or download the zip.

One more Enhancement

Some people like having the tooltip move along with the cursor, as long as the mouse is over the element. Sometimes it's nice to be able move the tooltip a little if it initially overlaps something important. Adding the basic functionality is pretty straightforward. Just bind the mousemove event to the same table element:

With the addition of lines 25 through 32, as the mouse moves over the links, the tooltip's top and left style properties are continually updated based on the mouse's position.

Try the demo and watch the tooltip move along with the mouse position, or download the zip.

The Plugin

The plugin doesn't offer much more than the scripts in this post, but feel free to try it out. One difference is that it doesn't rely on the .closest() method, so it can be used with jQuery 1.2.6 if you're stuck with that version for some reason. The syntax is a little funky:

The containerElement selector provides context so you can specify where exactly the event handlers are bound (unlike .live(), which binds to the document). The first argument of .eztip() is required. It should be a selector that matches the elements for which you wish to show a tooltip. The second argument is the typical options object, allowing for a handful of objects that you might expect to find in a stripped down tooltip plugin.

Let's Make Better Mistakes Tomorrow

The tooltip scripts in this post work fine, but they repeat code where they really shouldn't. Stay tuned tomorrow for a brief tutorial on one way to avoid such code repetition.

From traditional event listening to event delegation

Since an event occurring on an element is propagated to all of its ancestors, an event listener can be bound to a single ancestor of numerous elements instead of being bound to all the elements individually.

Consider the following list items:

If we want to display the class of an item when it is clicked, a traditional event listener in jQuery would be written like this:

The event object passed to the handler has a target property which corresponds to the element that has been clicked.

The equivalent using event delegation would look like this:

Event delegation has two main advantages:

1. setting a single event listener instead of multiple ones is obviously faster;
2. any new element later added to the list will have the same behavior (as demonstrated in Working with Events, Part 1).

This translation to event delegation that we've just made is, however, slightly too simple, since our original aim was to display only the class of the list items. Using the previous snippet, the class of the unordered list itself can be displayed (by clicking to the left of a bullet-point). We thus have to make sure that the target of the click is a <li>.

Scanning the ancestors of the event.target: the .closest() method

With such a simple document, event delegation is really that easy to achieve. But things can get more complex if the items have children elements:

In this case, if the user clicks on one of the words item, the event.target will be a <u>. It is therefore necessary to loop through all of the ancestors of this original target to find the element that is "interesting" for us: the <li>

Notice that if the user clicks outside of an <li>, we have to stop looping through the ancestors at some point; in this case when we find the root of the document (which has no parentNode).

jQuery 1.3 introduced the .closest() method, which replaces this loop by a single line of code:

The parameter passed to the .closest() method is a CSS selector that will match the first interesting ancestor.

The context parameter

It can be noted that, when the click occurs outside of an <li>, we could stop looping through the ancestors before hitting the document root, but instead as soon as we hit the <ul>. jQuery 1.4 will introduce an optional context parameter to .closest() for this purpose:

Here this is the <ul> element to which the event listener has been bound. This optional parameter improves the performance of event delegation as it prevents the wasted resources of searching for an ancestor which cannot exist.

Event delegation in a single line: the .live() method

jQuery 1.3 also introduces .live(), a method which binds the event listener and implicitly calls the .closest() method to determine whether your event handler should be executed or not.

Note how different the syntax using the .live() method is. It seems that we have switched back to a traditional event binding. However, a big difference is that the event listener will work for any existing and future element matching our original selector. There is, of course, nothing magic: behind the scenes .live() simply binds the event listener to the document root and filters any event.target using the .closest() method.

A notable difference with the traditional event binding syntax is that we are not using the target property of the event object inside our event handler, but rather the currentTarget. Indeed, the target of the event is possibly a child of one <li>, whereas the currentTarget property refers to the element that has been found by the implicit .closest().

As explained on the Event Object documentation, the currentTarget property is supposed to be the current DOM element within the event bubbling phase, i.e. the element on which the event has been detected by the event listener, which will always be the element on which the event listener was bound. When using .live(), the currentTarget would therefore always be the document root and you would need to use .closest() once again on the original target to find an interesting ancestor.

This kind of code is required with jQuery 1.3, but as of jQuery 1.4, the currentTarget is modified internally and can thus be used to avoid the extra .closest() inside the event handler.

The context parameter

In jQuery 1.3 all live event listeners were effectively bound to the document root. This can hurt the performance of a web page since all events detected by an event listener will trigger the execution of an implicit .closest(), even though the event target might be totally out of interest.

In jQuery 1.4, .live() should be able to bind the event listener to a specific and more focused element of the document by taking advantage of the context of your jQuery object:

The context is the second parameter used to build our jQuery object. To be useful for .live() it has to be set as a pure DOM element, hence the [0] after $("ul"). Brandon Aaron has a useful article explaining the context parameter in detail.

Unbind for .live(): the .die() method

Just like .bind() has its .unbind() counterpart that allows for event listeners to be unbound, .live() has its .die() counterpart.

Unlike .bind(), .live() does not allow for namespaced events to be used.

Dealing with events that don't bubble

There are some events for which event delegation is traditionally not possible, simply because they do not bubble. The promise of jQuery 1.4 is nevertheless to make those events compatible with .live(). How this is achieved will be covered in the upcoming fourth part of this tutorial.

The Styles

For the navigation items, I used a simple unordered list wrapped in a <div class="nav">. While the HTML structure is straightforward, the CSS is a little tricky, so I'll detail it here:

Most of the relevant CSS here has to do with positioning the nav items. I set the top <ul>'s left margin to 75 pixels less than the wrapper's width so that the top-level links appear on the right side. The 1600px width for the <ul> gives the floated list items ample room to line up horizontally next to each other.

The wrapper's overflow declaration is significant, as it hides the list items when they're sticking out to the right, but the rest is "window dressing."

Sliding the Nav

With the nav looking the way I want it at its initial state, it's time to make it do something. I'll start with a simple setup, having each "tab" (top-level item) slide to the left on the first click to reveal its sub-nav items, and slide back to its initial position when it's clicked a second time.

For this basic behavior, everything can be done inside a click handler for the top-level links. Note: Since I'm using multiple navs for this tutorial, each with its own set of behavior, I'll be referring to them by ID, unlike in the CSS snippet above, where everything is styled by class. There is nothing special about the selectors or their naming here. Name your own elements and select them however you want.

The first thing to do is set a few variables. The $parentItem variable is the <li> parent of the clicked link. The slideAmt is the width of the nested <ul>, which is the next sibling of the link. And direction will eventually determine whether the parent <li> should be slid to the left or to the right.

Notice the use of $(this). Inside the click handler, this refers to the clicked DOM element. By wrapping this in $(), we can call jQuery methods on it.

To get the sliding motion to occur, we can animate either the left property or the marginLeft property. Here, I'll animate marginLeft. So, the next thing to do is determine the direction of the animation based on the current value of marginLeft: If it's less than 0, direction is set to "+=", which increases it (back to 0); otherwise, direction is set to "-=". At the same time, an "expanded" class will be toggled so that the arrow background image can change directions.

Finally, we do the animation, plugging in the direction and slideAmt variables. The return false; line stops the default click action from occurring. Here is the finished code for the basic implementation:

Give it a try:

One at a Time

That's all well and good, but I don't really care for having more than one row of items expanded at a time. A couple simple modifications will fix that for us:

The links are stored in a variable first thing here. Whenever a link is clicked, all links have the "expanded" class removed. Of course, only one, at most, will have that class, but I'm lazy and it's easier to tell all of the links to remove the class than it is to hunt links that have the class first.

The same check is performed to set the direction of the animation. If the clicked link's parent <li> is going to be slid to the left, the link will also get the "expanded" class.

Finally, the clicked link's parent is animated in the direction and number of pixels specified by the variables. But here's the twist: all of that parent's siblings have their marginLeft property animated to 0. Again, I'm taking the lazy route, animating all of the siblings, even though one or none of them will need it.

Here's a demo of the "one at a time" version:

Auto-Collapse

Now that the expanding and collapsing are happening the way I like it, I'll add one more little touch. If the user's mouse leaves the containing <div class="tab-nav">, and stays out for a full second, any expanded list will collapse.

Line 2 declares a variable that will be used for the setTimeout(), which you can see tucked inside the .mouseleave() method near the bottom of the code. The setTimeout() function has two arguments: the first is an anonymous function that contains code for triggering the collapse of the list items, and the second is the number of milliseconds to wait (1,000 milliseconds) before the first argument (the anonymous function) is executed. The clearTimeout() inside the .mouseenter() method does what its name suggests: it clears the timeout. If the user mouses out of the nav area but then mouses back in before the 1000 milliseconds are up, the timer is stopped and the function will not be executed.

Note: The mouseenter(fn) and mouseleave(fn) shorthand methods are available as of jQuery 1.3. If you're still using jQuery 1.2.6, you can use .bind('mouseenter', fn) and .bind('mouseleave', fn) instead. Or, with just about any version of jQuery, you can use .hover(fn, fn).

Here is the final demo:

There are many ways to do this sort of thing. Just tweak the CSS or change the animation for a completely different experience.

Setting up Your Files for jQuery IntelliSense

First, set up jQuery on your page by downloading the latest version from the jQuery site.

Next, you will need to download the jQuery Documentation file from the jQuery site.

Download the files and add them to your project.

IntelliSense in external JavaScript files

At the top of the JavaScript file in which you would like to have jQuery IntelliSense enabled, you will need to add a line to reference the documentation file:

/// <reference path="jquery-1.3.2-vsdoc2.js" />

IntelliSense inline on your ASPX page

There are a couple of scenarios that may affect if you include a reference to the VSDOC file or not. If in doubt, just add a reference to the documentation file.

If you are linking to jQuery by the Google Code AJAX Library or are linking to jQuery from anywhere outside of your project you will need to reference the documentation file.

From each ASPX page you want jQuery IntelliSense you’ll want to call the reference within a server-side conditional statement so that the documentation file will still load in Visual Studio but will not load at run-time. Add the following after your jQuery declaration:

If you downloaded jQuery and saved it to your project Visual Studio will look for the vsdoc.js file automatically if the following conditions are met.

You've downloaded and installed the hotfix for Visual Studio.

jQuery and the documentation file need to be named the same with the exception that the documentation file end with -vsdoc.js. So when you add jQuery to your project make sure to rename them similarly. For instance, jquery-1.3.2.js is your jQuery library, Visual Studio will look for the documentation file at jquery-1.3.2-vsdoc.js and load it.

(Note: the jQuery 1.3.2 documentation file is named jquery-1.3.2-vsdoc2.js on the Download page so make sure you take out the 2 so that the file will be found by Visual Studio)

If you can't meet these conditions you'll need to reference the documentation file as shown above.

To test to make sure the documentation file loaded correctly, you can type $( and you should be presented with some documentation.

Additionally, you can type in $(document).r and you will be presented with a drop down of available options to choose from, one being "ready."

Now as you write your jQuery code, you'll be helped along by seeing what methods and properties are available to you.

Related Links

• Rich IntelliSense for jQuery
• jQuery and Microsoft
• jQuery, Microsoft and Nokia
• VS2008 SP1 Hotfix to Support "-vsdoc.js" IntelliSense Doc Files

1. I can't change jQuery's API.
2. Those shorthand methods used to be part of jQuery core, but with the release of 1.0, John Resig cleaned up the API quite a bit, removing all of the .unEvent() and .oneEvent() methods.

While I understand the desire for simplicity in developers' code and consistency in jQuery's API, I think Mr. Resig made the right decision removing the shorthand methods. Keeping both "un" and "one" shorthands in there would have meant an additional 44 methods, with very little gain for most users of the library. Nevertheless, it's fairly trivial to create a plugin for this sort of thing.

If we want the shorthand methods for a particular project, we can simply iterate through an array of event types and add the "un" or "one" method to the jQuery prototype (jQuery.fn). Here is what it might look like:

To add the "one" shorthand methods, we can repeat lines 8– 9, using one in place of both un in line 8 and unbind in line 9.

The script will respond to mouseover, mouseout, and click within <div class="entrytext">. I use mouseover/mouseout rather than mouseenter/mouseleave because the script relies on event bubbling. The $(event.target) selector ensures that the class manipulation occurs on the innermost element. You can try it out on this page by hovering over elements within the main content area.

The two classes that are being toggled have the following style rules:

The outline property is really handy for this sort of thing because it doesn't affect the element's dimensions or layout. Unfortunately, it isn't supported in Internet Explorer 6 or 7, so if you want to support them, you might want to use border or background-color instead in a separate IE-only stylesheet. Or, maybe IE has some proprietary property? Anyone know?

I'm not sure what the person wanted to do with this script. By itself, it doesn't seem particularly useful to me. Still, I think there are a few concepts in there that can be applied elsewhere, and maybe the script can be expanded to do something interesting.

Notice that the updated script also takes advantage of the .closest() method, which was introduced in jQuery 1.3. I don't want to apply the outline to any of the syntax-highlighted code in the entry, so I make sure that neither the event target nor any of its ancestors has a class of "syntax_hilite." Remember, to test for the presence (or absence) of a selector, we need to include more than just the selector itself. Here I test for "not a length." What I'm actually looking for is a length of 0, but since 0 is "falsey" the ! operator works just fine here.

One More Tip

Come to think of it, I can make the script shorter still by including the click event type along with mouseover and mouseout. Then, inside the the handler, the class that is toggled is determined by event.type.

Sometimes when code becomes shorter, it can also get less readable and more difficult to modify later on. I'm not suggesting that the final code snippet is necessarily the best way to achieve the outcome. A lot depends on what else you're planning to do and how a certain piece fits into the project as a whole.

The Bookmarklet

To use the bookmarklet, drag the following link to your bookmark/favorites list:

» [inline]jQuerify[/inline] «

Then, when you're on a page in which you want to play around with jQuery in the console, just click the bookmarklet.

Problems with the Other One

The biggest problem with the former version was that it didn't work when other libraries that use the $ function, such as Prototype and Mootools, were already loaded on the page. A number of people in the comments suggested that I simply add a jQuery.noConflict(); line to the script. But I wasn't crazy about the idea of having to use jQuery() instead of $() even if no other libraries had been loaded.

Another problem, one that I noticed while testing my new version, was that sometimes the jQuery file that I was inserting from the Google CDN wouldn't fully load by the time I attempted to use it later in the bookmarklet. At least, I think that's what was going on. In any case, it was throwing a "jQuery is not defined" error.

A Few Improvements in This One

To handle the problems, I'm having the script do a few things differently:

• Set up a counter to check 10 times if jQuery is loaded before giving up.
• Use a setTimeout to put a one-quarter-second (250ms) delay interval in between attempts.
• Check if the $() function is already being used by another library. If it is:
  • use jQuery's $.noConflict function to release the $() to the other library.
  • set $jq as an alias to jQuery for convenience.
  • mention in the flash notice that jQuery is in noConflict mode and that $jq() should be used instead of $().
• If after multiple attempts jQuery still won't load for some reason, set the flash notice's message accordingly and then remove it through plain old JavaScript rather than jQuery.

Here is the script in its unbookmarkleted form:

I'm sure it can be improved even further. If you have suggestions for making it more elegant, more efficient, more betterer, I would love to hear them in the comments.

Let me know if this one causes any problems.

Achieving the "optimum level" of customization is a bit of a balancing act… go too far either way and you've got an unusable plugin!

Bob and Sue

Let's say Bob has created a wicked new gallery plugin (called "superGallery") which takes a list of images and makes them navigable. Bob's thrown in some animation to make it more interesting. He's tried to make the plugin as customizable as possible, and has ended up with something like this:

The first thing that probably comes to your mind (ok, maybe not the first) is the prospect of how huge this plugin must be to accommodate such a level of customization. The plugin, if it weren't fictional, would probably be a lot larger than necessary. There are only so many kilobytes people will be willing to spend!

Now, our friend Bob thinks this is all fine; in fact, he's quite impressed with the plugin and its level of customization. He believes that all the options make for a more versatile solution, one which can be used in many different situations.

Sue, another friend of ours, has decided to use this new plugin. She has set up all of the options required and now has a working solution sitting in front of her. It's only five minutes later, after playing with the plugin, that she realizes the gallery would look much nicer if each image's width were animated at a slower speed. She hastily searches through Bob's documentation but finds no animateWidthDuration option!

Do you see the problem?

It's not really about how many options your plugin has; but what options it has!

Bob has gone a little over the top. The level of customization he's offering, while it may seem high, is actually quite low, especially considering all the possible things one might want to control when using this plugin. Bob has made the mistake of offering a lot of ridiculously specific options, rendering his plugin much more difficult to customize!

A better model

So it's pretty obvious: Bob needs a new customization model, one which does not relinquish control or abstract away the necessary details.

The reason Bob is so drawn to this high-level simplicity is that the jQuery framework very much lends itself to this mindset. Offering a previousButtonTextColor option is nice and simple, but let's face it, the vast majority of plugin users are going to want way more control!

Here are a few tips which should help you create a better set of customizable options for your plugins:

Don't create plugin-specific syntax

Developers who use your plugin shouldn't have to learn a new language or terminology just to get the job done.

Bob thought he was offering maximum customization with his delay option (look above). He made it so that with his plugin you can specify four different delays, "quite short," "very short," "quite long," or "very long":

Not only does this limit the level of control people have, but it takes up quite a bit of space. Twelve lines of code just to define the delaying time is a bit much, don't you think? A better way to construct this option would be to let plugin users specify the amount of time (in milliseconds) as a number, so that no processing of the option needs to take place.

The key here is not to diminish the level of control through your abstraction. Your abstraction, whatever it is, can be as simplistic as you want, but make sure that people who use your plugin will still have that much-sought-after low-level control! (By low-level I mean non-abstracted)

Give full control of elements

If your plugin creates elements to be used within the DOM, then it's a good idea to offer plugin users some way to access those elements. Sometimes this means giving certain elements IDs or classes. But note that your plugin shouldn't rely on these hooks internally:

A bad implementation:

A good implementation:

Notice that we've created a reference to the injected wrapper and we're also calling the 'attr' method to add any specified attributes to the element. So, in our settings it might be handled like this:

The $.extend() method will now recurse through all nested objects to give us a merged version of both the defaults and the passed options, giving the passed options precedence.

The plugin user now has the power to specify any attribute of that wrapper element — so if they require that there be a hook for any CSS styles then they can quite easily add a class or change the name of the ID without having to go digging around in plugin source.

The same model can be used to let the user define CSS styles:

Your plugin may have an associated StyleSheet where developers can add CSS styles. Even in this situation it's a good idea to offer some convenient way of setting styles in JavaScript, without having to use a selector to get at the elements.

Provide callback capabilities

What is a callback? - A callback is essentially a function to be called later, normally triggered by an event. It's passed as an argument, usually to the initiating call of a component. (in this case, a jQuery plugin).

If your plugin is driven by events then it might be a good idea to provide a callback capability for each event. Plus, you can create your own custom events and then provide callbacks for those. In this gallery plugin it might make sense to add an 'onImageShow' callback.

Instead of initiating the callback via traditional means (adding parenthesis) we're calling it in the context of 'this' which will be a reference to the image node. This means that you have access to the actual image node through the 'this' keyword within the callback:

Similarily you could add an "onImageHide" callback and numerous other ones...

The point with callbacks is to give plugin users an easy way to add additional functionality without digging around in the source.

Remember, it's a compromise

Your plugin is not going to be able to work in every situation. And equally, it's not going to be very useful if you offer no or very few methods of control. So, remember, it's always going to be a compromise. Three things you must always take into account are:

• Flexibility: How many situations will your plugin be able to deal with?
• Size: Does the size of your plugin correspond to its level of functionality? I.e. Would you use a very basic tooltip plugin if it was 20k in size? - Probably not!
• Performance: Does your plugin heavily process the options in any way? Does this effect speed? Is the overhead caused worth it for the end user?