[RESOLVED] how to stop click event from bubbling?

[sneakyimp]

I have a tree view thingy i'm working on. I have assigned an onclick event to an outer div which represents a tree view item and to an inner div which represents the open/close icon for that particular tree item if it has an sub-items.

Here's a simplified version of the html

<div id="itemN" nodeid="N" onclick="obj.click(this);">
  <table>
    <tr>
      <td>
        <div id="itemN_ci" onclick="obj.toggle(this);">&nbsp;</div>
      </td>
      <td>
        Item 21
      </td>
    </tr>
  </table>
</div>

The problem I'm having is that clicking on the inner div triggers both obj.click() and obj.toggle(). While this is not entirely surprising, it's not what I want. I'd like for the inner div to 'intercept' the event flow in the toggle() function so that it doesn't reach the click function.

I hope I'm making sense here. Any tips would be greatly appreciated.

[Weedpacket]

If memory serves, ending the event handler with "event.cancelBubble=true;" mgiht be enough.

But you'd have more control if you didn't use the "onclick" attribute but instead registered the event handler in a separate Javascript block that called each relevant element's "addEventListener" method.

[sneakyimp]

I was having a severe performance problem with large trees when I used the DOM approach to building them. I switched to one that built a big fat innerHTML string and it's about 30 times faster. This is why I'm doing the onClick thing. I could still probably write something to parse the tree once its rendered to add all of the eventListener stuff but I suspect that parsing the DOM tree to locate objects was the root of my performance issue.

At the moment, I have this working:

function myOnClick (el, evt) {
	// Firefox passes evt, IE does not thus we have...
	if (!evt) evt = window.event;

// I'm shocked this works but apparently it does...
if (evt.stopPropagation) evt.stopPropagation(); // for Firefox
evt.cancelBubble = true; // for IE

// grab some custom attributes from the element
var iNodeID = el.getAttribute('nodeID');
var childDivID = el.getAttribute('childDivID');

// do stuff...
}

The onclick assigned to the div tags is like this:

<div id="tree_445_i" class="itemDefault" onclick="myOnClick(this, arguments[0]);" nodeid="445" isselected="0" childDivID="tree_445_c">

It works perfectly for me in IE7 and Firefox 2. I have no idea about safari or opera or whatever. Putting arguments[0] in that onclick html was just something I tried on a whim so I tend to doubt that it does.

Javascript: wonk.

EDIT: I'm considering adding listeners to the tree and some other events and stuff but i'm a bit confused about how to add few listeners so that i:
save memory
avoid leaks
* avoid parsing the whole DOM to find each element thereby causing performance problems
while still being able to distinguish between event targets properly. If I add a 'click' event listener to my whole tree, I have a hard time determining what needs to be done unless I add more data to each of the DOM nodes I'm creating.

At the moment, I'm mulling over how best to connect actions to a particular node. Doing an onSelectNode sort of event seems like a good idea but I'm not sure how yet. The problem is partly about specifying a tree's structure in as little code as possible and partly avoiding an event listener on every single DOM node.

EDIT: At the moment, it's quite fast. On my intel machine (dual core 2.67ghz--unsurprsingly, the 2nd core doesn't help) it can render about 8000 nodes in firefox in about 2.5 seconds. IE takes much longer. I can't imagine ever needing that many nodes in a javascript tree but it's nice to know it can be done.

[Weedpacket]

Your divs have IDs. You don't need to traverse the entire DOM to find them if you have their IDs. Give them a common class and an XPath query would find them all.

Or you could just attach a handler to the entire tree that just asks the event itself what triggered it.

<div id="tree">
	<div id="foo1" class="toggleable default">
		<div id="foo2" class="toggleable">
		Foo1 -> Foo2
		</div>
		<div id="foo3" class="toggleable">
		Foo1 -> Foo3
			<div id="foo4">
			Foo1 -> Foo3 -> Foo4*
			</div>
			<div id="foo5" class="toggleable">
			Foo1 -> Foo3 -> Foo5
			</div>
		</div>
	</div>
</div>
<script type="text/javascript">
document.getElementById('tree').addEventListener('click',function(event){
	element = event.target;
	if(element.className.match(/\btoggleable\b/))
		alert("Hi from Element ID "+element.id);
},false);
</script>

sneakyimp wrote:

javascript: wonk.

Just remember: Javascript is not Java, or C, or anything else with similar syntax. In fact, the similarity of its syntax to those languages is something of a distraction. I suggest you have a look at Prototype (both the .js itself and the docs). Mildly enlightening.

[sneakyimp]

Thanks for the suggestion and the code! I'm starting to think the approach you are suggesting is likely the way to go. The main sticking point being that I have to add several additional attributes to several different DOM elements to work it. I like the class idea but feel that it is a bit of a misappropriation of the class name. I'm also working to make class names configurable so I don't think this will work.

A given tree item is not just a single DIV tag but several divs and a table to boot and any particular one that happens to field the click event (td, table, or one of 3 divs) must know its nodeID and what is to be done with the click, etc. Even so, I think I'm resigned to doing it.

[Weedpacket]

sneakyimp wrote:

I like the class idea but feel that it is a bit of a misappropriation of the class name.

No, it's what the class attribute is there for:

The class attribute has several roles in HTML:

• As a style sheet selector (when an author wishes to assign style information to a set of elements).

• For general purpose processing by user agents.

http://www.w3.org/TR/html401/struct/global.html#adef-class

It beats littering the HTML with nonstandard and nonvalidating attributes. Since, for example, you're presumably going to be styling selected nodes differently from non-selected nodes, the CSS rule would need some way to select those nodes. Also, no doubt you have some overall object to encapsulate all this: with an array of thingies with all their own properties and such, indexed by, say, ID so that you can just do an array lookup to match DOM element with thingy.

Then again, the target element is the target element, with all the properties and methods that that implies; childNodes, parentNode, tagName, addAttribute(), removeAttribute()...

[sneakyimp]

I hear you, and believe in my heart that it would be better to add one big fat event listener to my tree but resist the notion that I might lump some attributes critical to the proper function of my tree in with those that specify its appearance. It's all very messy. I cling to the compartmentalized custom attributes because they provide a mechanism through which I can keep the values segregated. I'll have to really be on my toes to avoid name collisions between the various types of data we're dumping in the collective class bucket--unique ids and whatnot.

And yet I have an abiding fear that my custom attribute will cause a name collision somehow.

In either case, I am presented with the chore of adding extra information to a significant variety of nodes so that when the target finally arrives at the event listener, I know what must be done.

sigh

[Weedpacket]

Well, like I said: no doubt you have some overall object to encapsulate all this: with an array of thingies with all their own properties and such, indexed by, say, ID so that you can just do an array lookup to match DOM element with thingy (I'd suggest making the DOM element itself a property of the thingy as well, but that's exactly the sort of thing that makes IE go wobbly.)

if(monkeys[event.target.id]) monkeys[event.target.id].scratch();

[sneakyimp]

Yep yep yep. that's what's keeping me afloat at the moment. My central data structure is an array of nodes that are multiply linked to each other (parent to child, sibling to sibling).

I have written an addEvenListener function for my class which appears to be working right nice. I'm still assigning those onclick bits inline but I'm wading into the addeventlistener stuff slowly. Thanks a lot for your guidance...I'm not sure I understand why you so generously waste your time on little things like this. It's nice to have someone who doesn't just throw the latest YUI code at you and say 'use this'.