Incoherent Babble

The Ultimate addEvent(..) function

sstchur — Thu, 25 Sep 2008 18:32:17 +0000

Two articles in particular that I've written on this blog have garnered a lot of positive feedback.

As time has gone on, I've seen mention of these articles pop up in programming forums here and there, and they still receive comments from time to time, which lets me know that people are still getting something out of them.

Unfortunately, the code in them is a tad dated. I've learned more and improved my code since I originally wrote them, and while these improvements have made their way into my Javascript Library, I know that the majority of people are just grabbing the code directly from the blog entries.

So I've decided to post an update: a sort of fusion between these two blog entries which offers functionality for addressing all of the issues discussed in the aforementioned entries (and then some).

I consider this new function the "Ultimate addEvent Function" because I really believe it addresses the large majority of cross-browser issues that people face when dealing with events in Javascript. And furthermore, this function goes beyond anything that any other Javascript library provides (at least as far as I know).

So without further ado, I offer to you:

sstchur's Ultimate addEvent(..) function!

            // call the actual function, using entity (the element) as the 'this' object
            _fn.call(_elem, e);

            // null out these properties to prevent memory leaks
            e.target = null;
            e.relatedTarget = null;
            e.preventDefault = null;
            e.stopPropagation = null;
            e = null;
         };

         // add the helper function to the event hash
         evtHash[key] = f;

         // hook up the event (IE style)
         _elem.attachEvent('on' + _evtName, f);

         key = null;
         f = null;
      }
   }
}();

xb.defineEvent = function(_evtName, _logicFn)
{
pseudoEvents[_evtName] = _logicFn;
};

// Helper Functions
function storeHandler(_key, _handler)
{
   evtHash[_key] = _handler;
}

function retrieveHandler(_key)
{
   return evtHash[_key];
}

function generateHandlerKey(_elem, _evtName, _handler)
{
   return '{' + getObjectGUID(_elem) + '/' + _evtName + '/' + getObjectGUID(_handler) + '}';
}

function isAnAncestorOf(_ancestor, _descendant, _generation)
{
   if (_ancestor === _descendant) { return false; }

   var gen = 0;
   while (_descendant && _descendant != _ancestor)
   {
      gen++;
      _descendant = _descendant.parentNode;
   }

   _generation = _generation || gen;
   return _descendant === _ancestor && _generation === gen;
}

function mouseEnter(_fn)
{
   var key = xb.Helper.getObjectGUID(_fn);
   var f = evtHash[key];
   if (typeof f === 'undefined')
   {
      f = evtHash[key] = function(_evt)
      {
         var relTarget = _evt.relatedTarget;
         if (this === relTarget || isAnAncestorOf(this, relTarget)) { return; }

         _fn.call(this, _evt);
      };
   }
   return f;
}

function getObjectGUID(_elem)
{
   if (_elem === window)
   {
      return 'theWindow';
   }
   else if (_elem === document)
   {
      return 'theDocument';
   }
   else if (typeof _elem.uniqueID !== 'undefined')
   {
      return _elem.uniqueID;
   }

   var ex = '__$$GUID$$__';
   if (typeof _elem[ex] === 'undefined')
   {
      _elem[ex] = ex + GUIDCounter++;
   }
   return _elem[ex];
}

})();

The code above, as is, won't work "out of the box" because (for the sake of brevity) I have not included the xb.removeEvent(..) function. Fear not however. There will be a link to a download of the full source code, complete with both xb.addEvent(..) and xb.removeEvent(..) at the end of this post.

Commentary

So some of you may be wondering: "Why another addEvent function. Haven't we been through this?" We have, but I think you'll find that this version does more than any other addEvent function you've seen. For example:

Works in all browsers that matter
Ensures one event wire up for any given element/event/handler combination (this is mostly for IE)
Forces IE to honor the this keyword from within event handler functions
Normalizes the wire up mechanism in all browsers (no need to include the "on" prefix for IE)
Forces IE to recognize the following properties/methods on event objects: .stopPropagation(), .preventDefault(), .target, .relatedTarget
Enhances Non-IE browsers to support mouseenter and mouseleave events
Provides an extension mechanism so developers can write their own custom events that plug right in ('mousewheel' or 'DOMContentReady' for example)

Given all that the Ultimate addEvent function does, it's not surprising that it has a bit of length to it. But it isn't super long, and I think it's well worth it.

Usage

Using the function(s) is just as easy as you'd expect:

var myDiv = document.getElementById('myDiv');
xb.addEvent(myDiv, 'click', clickHandler);

function clickHandler(e)

{
alert('The this keywords works (even in IE!): ' + this.id);
}

Extending Functionality

Since I mentioned that it was possible to extend the Ultimate addEvent function with custom events that plug right in, I figure I'd better offer an example. Actually, there already is an example built right into it. Both the mouseenter and mouseleave events utilize the extension mechanism internally, but for demonstration purposes, let's go ahead and add a mousewheel event:


	// Extend the Ultimate addEvent function to recognize a "mousewheel" event

xb.defineEvent('mousewheel', function(_fn, _useCapture, _listening)

{

   // event name for IE, Opera and Safari

   var evtName = 'mousewheel';
	   // hander for IE, Opera, and Safari

   var f = _fn;

   

   // if we're dealing with a Gecko browser, the event name

   // and handler need some adjustment

   var ua = navigator.userAgent.toLowerCase();

   if (ua.indexOf('khtml') === -1 && ua.indexOf('gecko') !== -1)

   {

      evtName = 'DOMMouseScroll';

      f = mouseWheel(_fn);

   }
	   // _listening represents whether this is an event attachment or detachment

   // that 5th parameter?  Don't worry about it; just always use false

   _listening ? xb.addEvent(this, evtName, f, _useCapture, false) : xb.removeEvent(this, evtName, f, _useCapture, false);

});
	// Helper function for dealing with mousewheel in Gecko browsers

function mouseWheel(_fn)

{

   var key = xb.Helper.getObjectGUID(_fn);

   var f = xb.Helper.retrieveHandler(key);

   if (typeof f === 'undefined')

   {

      f = function(_evt)

      {

         _evt.wheelDelta = -(_evt.detail);

         _fn.call(this, _evt);

         _evt.wheelDelta = null;

      };

      xb.Helper.storeHandler(key, f);

   }

   return f;

}
	I'm glossing over some details here because I don't want this post to get bogged down in something that it isn't really about, but I trust you get the idea.
	Most of this code actually comes from the The Gimme Javascript Library.  If you're using Gimme in any of your web pages, you already have all of this functionality for free.  The syntax is a touch different, but all the capabilities are the same.
	And if you happen to be the author of a Live Maps Mashup, you already have Gimme, as the latest version shipped with the most recent Virtual Earth MapControl.
	
	Complete Source
	As promised, here is the complete source, including both xb.addEvent(..) and xb.removeEvent(..)
	Enjoy! And please don't hesitate to send your feedback, both good and bad (I'm very willing to address issues or try to make requested enhancements).



Microsoft Releases New Version of Live Maps
sstchur — Thu, 25 Sep 2008 02:40:34 +0000
	Microsoft released a new version of Live Maps today.  This version features multi-way point routing as well as a number of other nice little updates.
	Another cool thing about this release is that it features Gimme quite prominently.  After getting directions, you'll notice the ability to expand/collapse the directions specific to each point along the route.  That nice, smooth animation you see is Gimme doing what Gimme does best!



Screw you, financially responsible Americans
sstchur — Sat, 26 Jul 2008 22:49:44 +0000
Be irresponsible, spend money you don't have, buy things you can't afford, fail to make the payments.  Not to worry -- just cry foul when it is threatened that it will be taken away from you and big government will come in and rescue you, sending the clear message that being financially responsible is, not only unnecessary, but actually stupid, since the tax dollars of those who are financially responsible are the dollars that are going to go towards this crappy legislature.

I've never been so irritated!


Wither IE6?
sstchur — Tue, 22 Jul 2008 13:00:07 +0000
Welcome aboard guys.  Glad you finally decided to start thinking about what I discussed long ago.


Firefox 3 .pageX / .pageY bug
sstchur — Thu, 03 Jul 2008 17:40:49 +0000
	Firefox 3 has a bug.  It's somewhat obscure, and it probably doesn't affect you, but it did affect me.
	It also affected the Microsoft Virtual Earth MapControl, so if you use the VE MapControl for a mashup, your Firefox 3 users are going to be affected by this issue.
	The issue?  It has to do with a mouse event's .pageX and .pageY properties.  The values of those properties are supposed to report the "page" position of the mouse cursor, relative to the upper-left corner of the HTML page.  You can think of it as the absolute (x,y) of the mouse cursor.
	The nice thing about .pageX/Y is that serves as an easy way to get the mouse position, regardless of how much (or even if) the browser window is scrolled.
	Contrast .pageX/Y with .clientX/Y:  the latter reports (x,y) coordinates relative to the upper-left corner of the browser window, so these values will be affected by browser scroll position.
	Anyway, at this point, you're probably thinking that I'm going to tell you that Firefox 3 reports the wrong values for .pageX/Y, and that that's the bug.  It's not that simple though (again, I admit this is a somewhat obscure bug).
	Most of the time, Firefox 3 reports the right values for .pageX/Y, but there is one case in which it doesn't.
	Manually Dispatching Events in Javascript
	A while back, I wrote a post about Re-routing events in Javascript.  In it, I explain how to create an event and initialize it with myEvt.initMouseEvents(..) (which takes a boat-load of parameters).
	Of all those parameters sent into .initMouseEvents(..), 4 are of particular interest: .screenX, .screenY, .clientX, and .clientY.
	Notice that .pageX and .pageY are not in the list.  You don't get the ability to pass in .pageX/Y when manually creating/dispatching an event in Javascipt.  Presumably, the values for these properties are computed based on .clientX/Y and the browser's scroll position.
	So for example, if you initialize a MouseEvent with .clientX = 200 and .clientY = 300, and if the browser is scrolled 50 x 75, then your event's .pageX and .pageY values will be 250 and 375 respectively.
	Oops!  I mean, that's what the values should be.
	The Bug
	Firefox 2 actually gets it right, but Firefox 3 doesn't.
	When you're manually dispatching a MouseEvent in Firefox 3, the .pageX/Y property values will always be equal to the .clientX/Y values, regardless of browser scroll position.
	As I previously mentioned, this affects the VE MapControl, so it's easy to see the issue in action.  Just use Firefox 3 and point your browser to http://maps.live.com.  Now make your browser window small enough to cause scroll bars to appear.  Scroll the browser window by some amount (doesn't matter how much) and try panning the map.  You should see the map "jump" during the initial pan.  The amount it "jumps" is going to be equal to the amount by which the browser window is scrolled.
	The Fix
	Microsoft has a work-around for this issue that is going to be released with the next version of Virtual Earth, but if you're a mashup dev using the VE MapControl, I've got a solution that you can use right now, and it goes like this:
	(function()

{

    var mouseEvt;

    if (typeof document.createEvent !== 'undefined')

    {

        mouseEvt = document.createEvent('MouseEvents');

    }

    if (mouseEvt && mouseEvt.__proto__ && mouseEvt.__proto__.__defineGetter__)

    {

        mouseEvt.__proto__.__defineGetter__('pageX', function()

        {

            return this.clientX + window.pageXOffset;

        });

        mouseEvt.__proto__.__defineGetter__('pageY', function()

        {

            return this.clientY + window.pageYOffset;

        });

    }

})();
	Just include the preceding code snippet anywhere in your HTML page.  The code is pretty straight-forward and just relies on the fact that Firefox (and others) have the ability to define getters through the use of .__defineGetter__(..).
	The .pageX/Y properties are read only, but it turns out that the browser will let you redefine these getters, thereby overriding their return logic.  Since the .clientX/Y properties appear to always report the correct value, all we have to do redefine the .pageX/Y getters to use a combination of .clientX/Y + .pageX/YOffset.
	In other words, we've redefined .pageX/Y to always return the position of the event (in our case, the mouse cursor since we're dealing with MouseEvents), relative to the upper-left corner of the browser window + the scrolled position of the browser -- what it should have been all along!
	This code doesn't hurt IE, as it won't execute in that browser, and it doesn't hurt Firefox 2 or other browsers that understand the code either, because the logic we've defined for the getters is going to be essentially the same as what the browser would have done natively anyway.
	I'd like to file a bug to Mozilla on this issue, but I haven't a clue as to how one goes about doing that.  If anyone knows (or wants to do it for me), feel free to speak up!
	Enjoy the fix!
	Comments welcome.



CSS Word-wrap: break word; (revisited)
sstchur — Mon, 30 Jun 2008 00:16:30 +0000
HedgerWow is a great blog.  If you've never checked it out, you definitely should.

I just noticed the other day that his latest post gives some props to my Emulating CSS word-wrap for Mozilla/Firefox blog post, but his version adds some much needed cross-browser support for browsers I neglected.

Nice One, HedgerWow!


Firefox 3
sstchur — Thu, 19 Jun 2008 14:45:50 +0000
Well unless you've been living under a rock, you know that Firefox 3 was released on Tuesday.  This is a big deal for me. When other browser makers release a new version, it's like eh... ok, that's cool (I guess).  But when Mozilla releases a new Firefox, I've got a brand new shiny app to get me through my day to day web browsing.

Besides the new theme (on Windows) being a little bland, FF3 does not disappoint!


Palindromes
sstchur — Sat, 14 Jun 2008 19:06:11 +0000
	The other evening while I was watching TV, I happened to have my laptop out, so I started dabbling around in Firebug just for the heck of it.  I'll often just start writing functions for no particular reason, other than to refresh my skills or perhaps discover something about Javascript that I hadn't previously known.
	So I was monkeying around, and I decided to write a function to determine if a string were a palindrome.  This is not a very difficult problem, but it might make for a descent introductory interview question (one of those questions you'd ask to rule out the truly inept).
	With problems like this, I'm mostly interested in two things:
	
	Writing the function in a clever way, so as to achieve the least amount of code possible
	Writing the function in the most efficient way possible
	
	Now, if it were Ruby, writing the clever solution (which might also happen to be the most efficient solution in that language -- not sure) would be ridiculously easy:
	def pal(s)

   s == s.reverse

end
	That's so trivial, it's probably not even worth writing.
	But Javascript doesn't have a .reverse() method on strings, so you have to take an extra step (still pretty easy though):
	function pal(s)

{

   return s === s.split('').reverse().join('');

}
	Split the string into an array, reverse the array, and then join it back together.  Since this is all native Javascript stuff, it turns out to be reasonably fast, though one might expect you could do better.
	For grins and giggles, I decided to see how a manual solution, where I compare characters starting at each end of the string and work towards the middle, would compare:
	function pal(s)

{

   var i, j,

   len = s.length,

   mid = Math.floor(len / 2);
	   for (i = 0, j = len - 1; i < mid; i++, j--)

   {

      if (s.charAt(i) !== s.charAt(j)) return false;

   }

   return true;

}
	This function will probably fail quickly, so that's good, but it also turns out to be generally faster than the split/reverse/join version.  It makes sense, since you're going through the string only one time and twice as fast as normal since you're traversing from both ends at the same time.
	Can you do even better though?  Maybe.  At least in Firefox you can, and quick tests seemed to confirm across other browsers too (but I didn't test extensively).
	What if we split the string in half, and only reverse half of it.  Then we can compare the first half with the original half:
	function pal(s)

{

   var len = s.length,

   x = len / 2,

   y = x === Math.floor(x) ? x : (x = Math.floor(x)) + 1;
	   return s.substr(0, x).split('').reverse().join('') === s.substr(y,len);

}
	The idea here is just split the string in half, reverse one of the two pieces and compare them.  For example:
	TOOT: splits into "TO" and "OT."  Reverse one of them, say the second part ("OT") and compare.
	If you've got a odd number of characters, you can ignore the middle most character:
	RACECAR: splits into "RAC" and "CAR" (ignore the "E" in the middle).  Reverse the second part ("CAR") and compare.
	As it turned out, this seemed to be faster than the other two methods.  Not by orders of magnitude, but not insignificantly either.  Here are the number from Firefox, running each function 10,000 time on the string "gohangasalamiimalasagnahog" (go hang a salami, i'm a lasagna hog).
	
	(Traverse from both ends): 797ms
	(Split/Reverse/Join): 969ms
	(Compare halves): 640ms
	
	Of course, numbers varied slightly during each run, but overall the they were consistent relative to each other.
	So there ya go.  Nothing in particular I wanted to point out here; just found it interesting and thought you might too.
	Think my code sucks?  Got a better solution?  Say so in the comments (you won't hurt my feelings).



Sneak Peek
sstchur — Wed, 11 Jun 2008 06:02:36 +0000
	I'm working on a new theme for my blog, as the dark colors are starting to hurt my eyes (maybe I am getting old).
	I'm going for something very minimalist this time around.  In fact, the name of the theme I'm working on is "Less Is More."
	Since I've recently installed a Theme Preview Plugin for Wordpress, I thought I'd leverage that to allow my readers to get a sneak peak of what the new theme will look like.
	Simply point your browser to: http://blog.stchur.com/?preview_theme=less-is-more.
	Feel free to offer feedback on what you like / don't like, but please remember that it's not done (should be done enough though to give you a basic idea of where I'm headed).
	For those of you reading from an RSS reader, come on over and check out the blog the "old fashioned way" for a change, so you too can get a sneak preview of the next Incoherent Babble theme.



Another Puzzle
sstchur — Mon, 09 Jun 2008 17:25:38 +0000
	Well after some significant thought, I have decided that I was either not given enough information to solve the puzzle in my last post, or I'm going to need a hint from the person who gave me the puzzle.
	Either way though, I don't have an answer to post as I promised I would, but not to worry... I have something better: another puzzle!
	This one I heard on NPR's Puzzle Master, so I know it is legit:
	
On a calculator display there are 5 digits.  The first 4 digits are: 8 7 3 5.  What is the fifth digit?

	It's not a trick question, and there is a simple and elegant solution to the puzzle.
	
	
	The fifth digit is 5 (so that the calclator display reads: 8 7 3 5 5).  Why?  Because it fits the pattern.  Digits displayed on a calculator are usually displayed with bars. For example a 3 would be displayed with 5 bars, like so:
	
_

_|

_|

	So if you start with an 8, you can easily figure out the pattern.  An 8 is made up of 7 bars, so 7 is the next digit.  A 7 is made up of 3 bars so 3 is the next digit.  A 3 is made up of 5 bars so 5 is the next digit.  And finally, a 5 is made up of 5 bars, so 5 is again the next digit.
	
	In case you're wondering, I heard this in the car listening to the radio, and I'd estimate that I drove about 5 miles or so before the answers came to me, so I'll guess that that was about 5 minutes.  How long did it take you to solve?
	Comments welcome.