Thanks for posting this question. I was facing the same problem. Your post and the comment did help me out. Thanks.

But going further, I am facing same problem as mentioned in comment #8. i.e “The only problem is that the id and event have scoping issues and will be bound to the last values they encountered as we set up all the onclicks…”

You certainly must have faced same problem. It would be great if you post how you work around that issue as well.

Thanks in advance..

Rahul

Unintended event capturing breaks pages for the minor browsers that support it (currently Opera and Safari, but soon Firefox 3).

function callGoto(e) {
  if (!e) e = event;
  var src = e.target || e.srcElement;
  while (src.nodeName != "TABLE") {
    if (src.nodeName == "TR") {
      if (src.class == "one" || src.class == "two" || src.id != "blah") {
        var id = src.id;
        return goto(id, conferenceID);
      }
    }
    src = src.parentNode;
  }
}

…though there’s probably a less clumsy way to roll all the innermost “if”s together, and that innermost “if” is probably pseudocode as it stands (I don’t think el.class is really valid, is it?). But that’s basically what I was meaning. Good to know that brute-forcing a click event onto every row of tables this size isn’t going to be a big performance loss.

Of course, absolutely none of this would be necessary if HTML5 restored the href attribute to all elements, which was one of the few things I thought XHTML2 got absolutely totally 110% correct. Then all I’d have to do is slap the necessary href on each tr element and be finished with this really stupidly simple requirement in twenty seconds instead of juggling a dozen script eggs in an attempt to make stuff clickable.

addEvent = (function () {
  return document.body.addEventListener ? function (e, ev, fn) {
    e.addEventListener(ev, fn, false);
  } : function () {
    e.attachEvent("on" + ev, fn);
  };
})();

// usage:
addEvent(element, 'click', function () {
  // do stuff
});

It’s a pretty common design pattern – it looks for the method to attach the events and creates the appropriate function.

Re: delegation to solve your problem. The way you’ve suggested, i.e. checking for a class to ignore particular rows would be the best way to do it (until we get data attributes in HTML5…) – but it wouldn’t be in the gotoCall function – it would be in the delegation code.

However, for the size of the table – there’s definitely isn’t going to be a measurable performance benefit. Go with what makes more sense to you now :-)

Update: thanks to PPK (who else?), I worked out how to add the table handler in a cross-browser fashion:

if (t.addEventListener) {t.addEventListener('click',callGoto,true);}
if (t.attachEvent) {t.attachEvent('onclick',callGoto);}

Not the most robust, perhaps, but it works well enough. I also figured out how to handle the event determination in a way that made sense to me, which was to set up a global variable and give it the needed value in my onLoad routine.

It was at that point I realized that event delegation probably won’t work well in my case, because not every row of the table should be clickable—in my current working file, about three out of ~35 rows are non-clickable. So it actually makes more sense for me to collect all the rows I want to make clickable and assign them their own event handlers, I think. The only way around it I can see is to do delegation and then have more code in ‘gotoCall’ that checks against a class or a list of IDs that should be ignored, and that seems kind of ugly. This table isn’t ever going to have more than 60 or 70 rows, and that’s a very padded estimate.

But I did learn a lot more about events and event handling, for which I thank you all!

var handleClick = function(event) {
// get the element inside the table that fired the event
var el = event.target; // add logic here for cross browser

// check if the element is a TR, if not then keep going up the
// DOM tree til you reach one and stop when you’re at the table
while(el.tagName != ‘TR’) {
el = el.parentNode;
if(el.tagName == ‘TABLE’) { // reached the table itself, passed any TR element, bail out
return;
}
}

// if you’re here, you got the TR and assuming it has an id, just call your function
goTo(el.id, event);
}

….

Oh wait, no, I don’t understand one part of it, which is the ‘idEventMap’ part. Sorry.

Oh, or how to do it so it works in IE7, which it doesn’t when I try it in such a way that it works in Gecko. Sorry again.

facepalm

Jeremy, I’ve no doubt I’m coding old-school, and I did try some of the functionality-testing code you suggest. It wasn’t helping (due to my botching the whole ‘onclick’ thing) so I took it out. Now that I’ve got things actually working thanks to all you awesome folks, I’ll start adding that kind of feature-detected code back in. I’ll also look into delegation and bubbling as suggested by ProggerPete and Justin.

e.g.
...
var size = mapStates.length;
for (x = 0; x < size; x++) {
...


or for brevity’s sake:

...
for (x = 0, size = mapStates.length; x < size; x++) {
...


In JavaScript the value of length could change for each iteration, so it’s evaluated each time through instead of just being checked like a variable would be. With all of the JavaScript being written for today’s “Web 2.0″ sites every millisecond counts, and since this is a learning exercise it’s better to learn the best practice!

One real difference you can notice in Javascript is that when the function is called as a method (ie, like obj.propertyname(arg1, arg2);), there is a special variable called this that has the value of the object that the method was called on (obj in the example). If a function is called directly (not “on an object”), this has the value of the “global object”, which is window in Javascript.