jobs wrote:
Hello,
[div flickering on mouseover/mouseout]
Popup.style.left = 220;
Popup.style.top = y - 10;
Just as a side note, positioning an element using hard-coded values may
be dangerous: a user can often resize his window, use big fonts, prevent
images from loading etc., which means that the tooltip could appear at
the wrong place (although your application, by design, may prevent it).
There are ways to retrieve absolute position of an element, and then use
it to position another element in regards of this position, even taking
care of scroll levels.
<td onmouseover="ShowTooltip('DE043512-6815-45A9-936E-D5D5AD8F100B
');" onmouseout="HideTooltip();">
Ah, the .Net framework... so neat :)
I cannot test it, but my bet would be that your problem is related to
what is called event flow, i.e. the way an event is created and then
traverses elements.
The theory states that an event is created at the document node, then
traverses the DOM tree in three phases:
[1] Phase one is called the capturing phase. The event traverses all
parent elements until it reaches the target node. For instance, if you
click on a DIV that is inside the BODY, the event will visit the
document node and the BODY node, triggering all event handlers defined
on these elements defined for the capturing phase.
[2] Phase two is called the target phase. The event has reached the
target node, triggering all event handlers defined on these elements for
the target phase (those are the same as the ones defined for the third
phase, the bubbling phase).
[3] Phase three is called the bubbling phase. The event goes back to the
document node, triggering all event handlers defined on the parent
elements for the bubbling phase.
<URL:http://www.w3.org/TR/2006/WD-DOM-Level-3-Events-20060413/events.html>
The way you use to define your handler specifies the phase. If you use
addEventListener, then the phase is decided by the third argument. If
you use the simple assignment "element.onevent=function(evt)", or
attachEvent, then it's considered target/bubbling phase.
Now, consider how mouseover and mouseout events are created. You can
only mouse over one element at a time. This means that the element your
mouse is coming from is moused out, while the element your mouse is
going to is moused over - even if the two elements are nested (what
matters is what element is visually moused over).
With all this, we should be able to devise some hypothesis about your
flickering problem.
Consider two nested elements, with the outer element having bubbling
handlers, like in your example (the inner element has no handlers).
Imagine your mouse is already on the outer element, but still not over
the inner one. When you mouse over the inner element, a mouseout event
is fired from the outer element, triggering the mouseout handler. Then,
a mouseover is fired on the inner element, triggering no handler there
(since there's none defined for this element), however bubbling to the
outer element, triggering its mouseover handler.
---
<div
onmouseover="foo('div','mouseover')"
onmouseout="foo('div','mouseout')">
This is a nested
<b onmouseover="foo('span','mouseover')"
onmouseout="foo('span','mouseout')">element</b>
</div>
<br>
<div id="console"></div>
<script type="text/javascript">
function foo(el, evt) {
var console=document.getElementById("console");
console.appendChild(
document.createTextNode("element:"+el+";event:"+ev t)
);
console.appendChild(
document.createElement("br")
);
}
</script>
---
To sum it up : your mouse was always on the outer element, however the
mouseout handler, followed by the mouseover handler, have been
triggered: this gives you a flickering effect if your handlers have
instructions to show/hide some concerned element. Check in your code
whether the combination of elements does not yield this situation.
If so, how to solve this? Defining a phase for your handler could be a
good idea, however I do not really know whether all user agents really
support this feature correctly - some do, some do not. So prefer... the
following second solution.
In your handler, you have to determine whether the event originates from
some inner element, in which case you should not execute the mouseout or
mouseover effects, since they are technically not needed. To determine
this, event models offer many properties on the event object. In IE's
model, you'd study the toElement and fromElement properties, and in
W3C's model you'd study the relatedTarget property. Searching these
keywords in comp.lang.javascript archives located at
http://groups.google.com will give you working examples.
Also, IE offers special events (onmouseenter and onmouseleave IIRC),
which can be used to replace onmouseover and onmouseout. I do not know
whether other user agents implement these.
HTH,
Elegie.
