var gDebugCounter = 0;
function debug(o) {
	if(IS_DEBUG) {
		var li = document.createElement("LI");
		li.innerHTML="<span class='counter'>("+gDebugCounter+")</span> " + o;
		var tempLogger = xGetElementById("tempLogger");

		if(tempLogger.insertAdjacentElement) tempLogger.insertAdjacentElement("afterBegin", li); // IE
		else tempLogger.appendChild(li); // Mozilla

		gDebugCounter++;
	}
}



// workingHere:one hour out from Utah2
// IE shows 2x,3x mouseOver proportional to level of li
// trying to see if it does this in Firefox, too, but can't until I can
// make the basic system work in Firefox. It appears that insertBefore doesn't 
// work in Firefox, but appendChild() does. And, it seems to work in IE, too.
// So I have remaining all replacements to make except for the one above. 
// April 1, 2006. 1:05AM

// April 2, 2006 11:15PM
// The 2x and 3x appears to be because the sub LIs fire the parent LI mouseovers
// This is true for both IE and Firefox.
// Let's see about cancelling the bubble...
// this doesn't work, as after the event is cancelled, I get undefine (even if I copy the target of the event into a var).

// April 4, 2006 2:27AM
// Since I just discoved that the above (cancel event) doesn't work (or works too well)
// I will instead need to stop responding to any event that is the same navItem as the previous/last

// April 4, 2006 5:09PM
// Made major progress on deciding when to mouseOut of parent
// Now the problem is, if going from 1 --> 1_a slowly, everything is fine.
// But, if quickly 1 --> 1_a, then 1_a_1 appears and then the whole thing disappears.
// 1_a_1 types always disappear if truly moused over.

// April 12, 2006 12:55PM
// Using the new node-walk stack-comparison technique, I now am correctly
// hiding subnav of second level if going from subnav of 2nd directly over
// a different second level. e.g., 1_c_3 --> 1_e,
// but there are still other problems:
//
// 1_c_3 --> 1_d --> 1_c leaves the 1_d subnav showing, along with opening the 1_c subnav
// And then, in same operation, 1_c --> 1 hides the 1 subnav (it shouldn't)
// and shows the over/off indicator as off. Actually, this last one is always the case.

// April 14, 2006 4:11PM
// Was trying to attach over/out to the UL so that I new when to out the entire
// nav region. The problem is, the src ele for the UL out is the LI.
// So, instead, I am going simply track the last mouseOut event and if there is no
// mouseOver w/in a certain amount of time (on any ele), then assume the mouse
// has left the nav region, and thus, reset the entire nav.
//
// Also remaining: make the nav again work in Firefox.

// April 16, 2006 11:36PM
// Planet Hollywood in Times Square for tomorrow's Expressions training.
// The Navregion out is throwing and exception -- just built and has yet to work.
// 12:16. Figured it out. I was calling this[navbar].cleanStack() for the setTimeout.
// There is no navbar.cleanStack -- it is a static method that take the stack as a param.
// Which presents a new prob. I can't called a method w/ a param for the setTimeout,
// so I'll have to refactor the cleanStack and all its callers.
// Leaving Planet Hollywood after having almost an entire sampler.

// April 18, 2006 2:07PM
// All seems to be working in IE.
// Now on to Firefox.

// April 19, 2006 11:26PM
// ID:pr10
// At the Marriot Marqui View rotating lounge -- lost my camera today
// Fucking thing. Since moving to placing the timeout object on each item, rather than
// the parent Nav (which I had to do), I now need to clear all child timeouts when over
// an item. Otherwise, when going from 2_b_1 --> 2_b, the 2_b_1 out will fire before the 
// 2_b over fires. And then, poof, the whole tree is moused out. But, now that I think about it, 
// since I have shut off the NavOut region thing, then a 2_b_1 out should only hide the 2_b_1,
// not its parent. So, maybe there is a bug in the clearStack method.
//
// Until writing this (while wrapping up dev for the night), I didn't consider the above last sentence.
// Instead, I started to write a resetChildOutTimers method. But, considering the above, that might
// not be necessary after all. I'll need to investigate in the morning. What a pain in the ass.
// No wonder why this takes so long, just writing that up took five -- nope, six -- minutes!

// April 24, 2006 3:02PM
// Alpha state.
// I finally found the nasty bug. me.isOver was false when mouseOut ran, so the submenu
// was never being deactivated.
// Test case: 2_a_1 --> 2_a --> 2b. 2_a_1 would remain visible.