Highlight a table cell with its content

V

VK

Hi, I'm playing around with tables (TOM vs. DOM etc.)
I cannot figure out an effective highlight mechanics for the cells:

1) No problems with:
<td ...onMouseOver/Out background change>
some text inside
</td>

2)
<td ...onMouseOver/Out background change>
<input type="checkbox" name="cb022" value="cbv022">
some text inside
<some href inside>
</td>

In the second case (as expected) we are getting a bubbly fountain of
mouseover/mouseout events while moving over the cell: from the cell itself
and from the content elements. So the cell blinks, or the link is not
painted but not the cell, or the link is painted, but the cell is not, and
so on.

What would be any more or less simple way to:
onmouseover paint the cell and all its content
keep it all painted until you leave the cell
?
 
R

RobG

VK wrote:
[...]
In the second case (as expected) we are getting a bubbly fountain of
mouseover/mouseout events while moving over the cell: from the cell itself
and from the content elements. So the cell blinks, or the link is not
painted but not the cell, or the link is painted, but the cell is not, and
so on.

Not really as expected. Have you messed with the default inline/block
attributes of the elements you are using?
What would be any more or less simple way to:
onmouseover paint the cell and all its content
keep it all painted until you leave the cell
?

I think you post has languished because this is really a CSS thing, and
nothing to do with JavaScript.

I can't replicate your issue in Firefox or IE 6, the closest I can get
is to put a different background on the href using a:hover
{background-color: red}, but I would expect that to look awful.

Below is the code I used to test your issue, if it doesn't "flash" for
you then your issue is elsewhere. Try

comp.infosystems.www.authoring.stylesheets

for more help

--
Rob
</script>
<style type="text/css">
a:hover {background-color: red;}
</style>
</head>
<body>
<form action="">
<input type="text" name="xx" value=' '><br>
<input type="button" value="click me"
onclick="testNull(this.form.xx.value);">
</form>
<table border="1">
<tr>
<td onmouseover="this.style.backgroundColor = 'blue';"
onmouseout="this.style.backgroundColor = 'pink';">
<p>Here is a test</p>
<form action="">
<label>Click for nothing to happen...&nbsp;
<input type="checkbox" name="cb022" value="cbv022">
</label>
a bit of text
</form><br>
a bit more text
<a href="http://www.microsoft.com"><br>
Link to Microsoft<br></a>
and even more text
</td>
<td onmouseover="this.style.backgroundColor = 'red';"
onmouseout="this.style.backgroundColor = 'pink';">
<p>Here is a test</p>
<form action="">
<label>Click for nothing to happen...&nbsp;
<input type="checkbox" name="cb022" value="cbv022">
</label>
a bit of text
</form><br>
a bit more text
<a href="http://www.apple.com"><br>Link to Apple<br></a>
and even more text
</td>
</tr>
</table>
 
V

VK

I'm talking about external table manipulation (table is by itself, the
script by itself).
Also, form elements are all appeirtaning to one enclosing form (how is it in
the real life, doesn't affect the showcase, just to mention the code
change).

From your example:
(I know it's MICROSOFT style, DOM is coming a bit later).

Try to move over the right cell. Is it something with my code or with the
browser? And how to fix it?

<html>
<head>
<script>
function test() {
var c = document.getElementById('table01').tBodies[0].rows[0].cells[1];
c.attachEvent('onmouseover',highlight);
c.attachEvent('onmouseout',restore);
}
function highlight() {
event.srcElement.style.backgroundColor='red';
}
function restore() {
event.srcElement.style.backgroundColor='white';
}
</script>
</head>
<body onLoad="test()">
<table id="table01" border="1">
<form action="">
<tr>
<td onmouseover="this.style.backgroundColor = 'blue';"
onmouseout="this.style.backgroundColor = 'pink';">
<p>Here is a test</p>
<label>Click for nothing to happen...&nbsp;
<input type="checkbox" name="cb022" value="cbv022">
</label>
a bit of text
<br>
a bit more text
<a href="http://www.microsoft.com"><br>
Link to Microsoft<br></a>
and even more text
</td>
<td>
<p>Here is a test</p>
<label>Click for nothing to happen...&nbsp;
<input type="checkbox" name="cb022" value="cbv022">
</label>
a bit of text
<br>
a bit more text
<a href="http://www.apple.com"><br>Link to Apple<br></a>
and even more text
</td>
</tr>
</form>
</table>
</body>
</html>
 
M

Michael Winter

[snip]
Is it something with my code or with the browser?

Technically neither as there is nothing "wrong" here. However, the effect
is due to your code.

What you either don't realise, or have forgotten, is that events "bubble".

An event might initially be triggered on a certain element, but once it
has finished there, the event then continues up the document tree, firing
additional listeners as it goes. As you base the colour change on the
source of the event, you end up changing the colour of the cell when you
mouse-over the cell, and the colour of descendents separately when you
mouse-over them.
And how to fix it?

Don't change the colour of the source element, just the cell (as you do
with the intrinsic events in the first cell).

To do that purely in script, you'll have to abandon attachEvent as it
doesn't set the this operator correctly.

If you're only attaching one event listener per element,

function highlight() {
this.style.backgroundColor = ...;
}
function restore() {
this.style.backgroundColor = '';
}

elementRef.onmouseover = highlight;
elementRef.onmouseout = restore;

will suffice (with proper feature testing, of course). If there will be
multiple listeners, you'll need something more advanced (say if that's the
case).

[snip]

Mike
 
V

VK

What you either don't realise, or have forgotten, is that events "bubble".
Of course I remember that, I just was wondering how to "poke" only the right
bubbles :)
To do that purely in script, you'll have to abandon attachEvent as it
doesn't set the this operator correctly.

I'm getting there... As I understand,

objRef.onEvent = someFunction;
creates some kind of "exclusive" event listener: objRef gets only the events
originated from it and for it.

objRef.attachEvent('event', someFunction);
attaches objRef to the "bubble stream", so it receives all events originated
from it also as from all underlying event producers.

Am I right or attachEvent is simply broken in IE?
 
M

Michael Winter

Of course I remember that, I just was wondering how to "poke" only the
right bubbles :)

Fair enough.

You could compare the value of the this operator with the event's target
(or srcElement) property. That would tell you if you're leaving the cell
or a descendent, however:

1) You'd still have to avoid attachEvent.
2) If you set style properties using the event target, rather than
on the cell only, this will cause the style properties on
descendants to persist once you've left the cell.

So, my previous advice stands: only manipulate the cell.
I'm getting there... As I understand,

objRef.onEvent = someFunction;
creates some kind of "exclusive" event listener: objRef gets only the
events originated from it and for it.

objRef.attachEvent('event', someFunction);
attaches objRef to the "bubble stream", so it receives all events
originated from it also as from all underlying event producers.

Am I right or attachEvent is simply broken in IE?

No and yes. :)

It doesn't matter how you add an event listener to an element. It will
always play a full role in the event flow[1].

The W3C DOM specifies a currentTarget event property which refers to the
event's present location in the document tree, and a target event property
which refers to the original dispatch point for the event. IE only
provides the latter in srcElement, leaving the this operator your only
option for knowing the current target. As attachEvent doesn't set this
properly, I'd say yes, it's broken.

That help?

Mike


[1] Capturing event listeners are an exception, but IE doesn't implement a
capturing phase.
 
R

RobG

Michael Winter wrote:
[...]
1) You'd still have to avoid attachEvent.
2) If you set style properties using the event target, rather than
on the cell only, this will cause the style properties on
descendants to persist once you've left the cell.

So, my previous advice stands: only manipulate the cell.
[...]

The sample attachEvent code posted by the OP works in IE but not
Firefox - the code gets to c.attacheEvent() and fails with:

c.attachEvent is not a function

As far as I can discover, attacheEvent is a Microsoft invention and
should probably be avoided for that reason alone.
 
M

Michael Winter

[snip]
The sample attachEvent code posted by the OP works in IE but not
Firefox - the code gets to c.attacheEvent() and fails with:

c.attachEvent is not a function

I know. It should. :)
As far as I can discover, attacheEvent is a Microsoft invention

Yes, it is.
and should probably be avoided for that reason alone.

The (possible) reason for using attachEvent is that like addEventListener
from the W3C DOM Events module, it allows you to attach multiple event
listeners to the same element without destroying any existing ones.

However, it's possible to provide the same functionality through the
on<event> properties with some supporting code, so I'd use
addEventListener when possible and on<event> with support otherwise.

Mike
 
M

Michael Winter

[snip]

A quick bit of caution: a small part of that page is incorrect. In the
"Turning it off" section, it states:

"Stopping event propagation in the capturing phase is impossible.
One wonders why."

This simply isn't true. From section 1.2.2 - Event capture (pg. 11) of the
Specification:

"If the capturing EventListener wishes to prevent further
processing of the event from occurring it may call the
stopProgagation method of the Event interface. This will prevent
further dispatch of the event [...]."

Mike
 
V

VK


An old dust by now, but just to mention: I personally don't think that NN4
model was so bad.
The only thing I will never forgive them: the cursor keys were excluded from
onKeyXXX event branch. Bad boys!!! :)

Overall up to down event model (with a proper use of event listeners check
and further event delivery) provides a much cleaner way to handle events. It
was maybe just a bit too "academic" and requiring too much of coding
discipline from average users. Bubbles are more evident and 'quick-n'-durty
coding friendly'.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,771
Messages
2,569,587
Members
45,097
Latest member
RayE496148
Top