clicking on list elements - problem

A

abs

Hi all.

My list:

<ul>
<li id="a" onclick="show(this)">Aaaaaaaa</li>
<li id="b" onclick="show(this)">Bbbbbbbb</li>
<li id="c" onclick="show(this)">Cccccccc
<ul>
<li id="d" onclick="show(this)">111111</li>
<li id="e" onclick="show(this)">222222</li>
<li id="f" onclick="show(this)">333333
<ul>
<li id="g" onclick="show(this)">@@@@@@@@@</li>
<li id="h" onclick="show(this)">{{{{{{{}</li>
<li id="i" onclick="show(this)">????>>>>></li>
</ul>
</li>
</ul>
</li>
</ul>

<ul>
<li id="j" onclick="show(this)">qqq</li>
<li id="k" onclick="show(this)">vvvv</li>
</ul>

And function:

function show(clicked)
{
alert(clicked.id)
}

The trouble is that when I click on the list element having id="g", there
appear three alerts one by one showing "g", then "f", and "c". Prabably
that's because those element are nested. How could I prevent showing the id
of clicked element and its parents ? I'd like only clicked element's id to
be showed.

Best regards,
ABS
 
V

VK

The best trick for all this event mess so far I found is from Lasse
Reichstein Nielsen:
....
<li id="i" onclick="show(this, (event.target||event.srcElement))">Some
text­</li>
....

function show(src,trg) {
if (src == trg) {
alert(src.id);
}
}

Works for IE 6.x and FF 1.0.3/4
 
R

RobB

abs said:
Hi all.

My list:

<ul>
<li id="a" onclick="show(this)">Aaaaaaaa</li>
<li id="b" onclick="show(this)">Bbbbbbbb</li>
<li id="c" onclick="show(this)">Cccccccc
<ul>
<li id="d" onclick="show(this)">111111</li>
<li id="e" onclick="show(this)">222222</li>
<li id="f" onclick="show(this)">333333
<ul>
<li id="g" onclick="show(this)">@@@@@@@@@</li>
<li id="h" onclick="show(this)">{{{{{{{}</li>
<li id="i" onclick="show(this)">????>>>>></li>
</ul>
</li>
</ul>
</li>
</ul>

<ul>
<li id="j" onclick="show(this)">qqq</li>
<li id="k" onclick="show(this)">vvvv</li>
</ul>

And function:

function show(clicked)
{
alert(clicked.id)
}

The trouble is that when I click on the list element having id="g", there
appear three alerts one by one showing "g", then "f", and "c". Prabably
that's because those element are nested. How could I prevent showing the id
of clicked element and its parents ? I'd like only clicked element's id to
be showed.

Best regards,
ABS
Click to expand...

Might want to consider a more global approach to handling those
clicks...

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<style type="text/css">

li {
background: #ddd;
margin: 2px 0;
cursor: pointer;
}

</style>
<script type="text/javascript">

document.onclick = function(e)
{
var tgt;
if ((e = e || window.event)
&& (tgt = e.srcElement || e.target)
&& /LI/i.test(tgt.nodeName))
{
alert(tgt.id);
}
}

</script>
</head>
<body>
<ul>
<li id="a">Aaaaaaaa</li>
<li id="b">Bbbbbbbb</li>
<li id="c">Cccccccc
<ul>
<li id="d">111111</li>
<li id="e">222222</li>
<li id="f">333333
<ul>
<li id="g">@@@@@@@@@</li>
<li id="h">{{{{{{{}</li>
<li id="i">????>>>>></li>
</ul>
</li>
</ul>
</li>
</ul>
<ul>
<li id="j">qqq</li>
<li id="k">vvvv</li>
</ul>
</body>
</html>
 
R

RobB

abs said:
But there'e one problem. When I add onclick to element like this:

liElement.onclick = function(){show(this, (event.target||event.srcElement))}

If then I click the element, Firefox claims: "Error: event is not defined".
But when I define onclick inline, like here

<li id="i" onclick="show(this,
(event.target||event.srcElement))">Sometext­</li>

everything's fine with click and works. So, what's the difference and
where's the problem ?

ABS
Click to expand...

Glad to hear it. Try...

liElement.onclick = function(e){show(this, (e.target||e.srcElement))}

When you register a handler programmatically (JS) the mozilla Event
object is automatically passed to your handler as arguments[0]. You
need to catch it at the other end, even if the handler is a wrapper (as
above). Handlers assigned in HTML are wrapped automatically and the
Event object is exposed as the local variable 'event'.
 
R

RobB

Oops, cross-browser...

liElement.onclick = function(e)
{
if (!e) e = window.event;
show(this, (e.target||e.srcElement))
}
 
M

Michael Winter

abs said:
But there'e one problem. [...]

liElement.onclick = function(){show(this,
(event.target||event.srcElement))}
Click to expand...

The IE event model differs from that used by most user agents, and the one
defined by the W3C. IE uses a global object called event to communicate
event-related information, whereas the W3C/Netscape model passes the event
object to listeners as an argument.

When a user agent encounters an intrinsic event in markup, it creates an
anonymous function that contains the code. Here, again, we find
differences.

When parsing

<element on<type>="/* User code */">

IE produces an intrinsic event listener like:

element.on<type> = function() {
/* User code */
};

This is fine because the event object is global in IE (and any user agents
that choose to follow it), so it can still be accessed. However, user
agents that follow the Netscape/W3C event model internally produce
intrinsic event listeners like:

element.on<type> = function(event) {
/* User code */
};

That is, they pass a reference to the event object with the identifier,
'event', to listeners. In your code, you don't try to access this argument,
so Firefox and others will not find an event object.

Change your code to:

liElement.onclick = function(e) {
e = e || event; /* Use either the argument, if supplied,
* or the global object.
*/
show(this, e.target || e.srcElement);
};

[snip]

There is one potential problem: your code will only work if the target
element is what you expect. If you have any other elements within the list
item, the target is likely to be one of those elements. Just keep that in
mind.

Mike
 
V

VK

Here the better variant I have by now. I coming to the conclusion that
it's better don't use intristic event handlers in NN/FF, they are too
unstable.
It gives your more code in the <script> section, but you keep your <ul>
lists nice and clean. W3 should be happy: scripting, styling and
content are all separate and independent :)

<html>
<head>
<title>UL's</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script>
var isDOM = window.addEventListener;

function init() {
var foo = null;
var tmp = document.getElementsByTagName('LI');
for (i=0;i<tmp.length;i++) {
/* Add EventListener on the capturing phase
so we don't have to bother with bubbles history */
foo = (isDOM)?
tmp.addEventListener('click',test,true) :
tmp.attachEvent('onclick',test);
}
}

function test(e) {
var tmp = '';
if (isDOM) {
e.stopPropagation();
tmp = e.target.innerHTML;
}
else {
event.cancelBubble = true;
tmp = event.srcElement.innerHTML;
}
alert(tmp);
}

window.onload = init;
</script>
</head>

<body bgcolor="#FFFFFF">
<ul>
<li>Level 1 - Item 1</li>
<li>Level 1 - Item 2
<ul>
<li>Level 2 - Item 1</li>
<li>Level 2 - Item 2
<ul>
<li>Level 3 - Item 1</li>
<li>Level 3 - Item 2</li>
<li>Level 3 - Item 3</li>
</ul>
</li>
<li>Level 2 - Item 3</li>
</ul>
</li>
<li>Level 1 - Item 3</li>
</ul>
</body>
</html>
 
R

RobG

VK said:
Here the better variant I have by now. I coming to the conclusion that
it's better don't use intristic event handlers in NN/FF, they are too
unstable.
Click to expand...

You have complained a number of times in recent posts about 'NN/FF',
but generally your discoveries have only shown the variances between IE
and Mozilla event models. That does not make Mozilla-based browsers
'unstable', it just means you have to take account of both event
models in your code.

Does adding an event handler dynamically avoid intrinsic events, or is
it just a different way of adding them?
It gives your more code in the <script> section, but you keep your <ul>
lists nice and clean. W3 should be happy: scripting, styling and
content are all separate and independent :)

<html>
<head>
<title>UL's</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script>
var isDOM = window.addEventListener;

function init() {
var foo = null;
var tmp = document.getElementsByTagName('LI');
for (i=0;i<tmp.length;i++) {
/* Add EventListener on the capturing phase
so we don't have to bother with bubbles history */
foo = (isDOM)?
tmp.addEventListener('click',test,true) :
tmp.attachEvent('onclick',test);
}
}

function test(e) {
var tmp = '';
if (isDOM) {
e.stopPropagation();
tmp = e.target.innerHTML;
}
else {
event.cancelBubble = true;
tmp = event.srcElement.innerHTML;
}
alert(tmp);
}

window.onload = init;
</script>
Click to expand...


To support older browsers, the following may suit:

function show(x) {
alert( (x.id || 'No id') + '\n' + x.innerHTML);
}


function init(){

if (document.getElementsByTagName){
var lis = document.getElementsByTagName('LI');
} else if (document.all){
var lis = document.all.tags('LI');
} else {
return;
}

var i=lis.length;
while (i--){
lis.onclick = function(e) {
e = e || window.event;
e.cancelBubble = true;
if (e.stopPropagation) e.stopPropagation();
show(this);
}
}
}
 
V

VK

Does adding an event handler dynamically
avoid intrinsic events, or is it just a different way of adding them?
Click to expand...

Using intrinsic events forces you to use the non-documented EVENT
object in FF (Some people tried to say here that this is some special
EVENT and it has nothing to do by its nature with window.event in IE).

<html>
<head>
<title>Event</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>
<body>
<p onclick="alert(event.target)">Test</p>
</body>
</html>

Click and get it. I did not create this EVENT object, nevertheless it's
available and self-updating. Thus it's a global public self-updating
event object. Thus it's equal to windows.event in IE. (By trying to
find some contextual differences we would have some religious
discussion here, sort of is Mary holy or is she just God's mother). But
Mozilla is dead silent about this object. They don't promise us any
properties or behaviours. So better use dynamic handlers. They are much
more flexible and in case if something doesn't work, we can always say
"hey, look what did you say and what do we have!".
 
M

Michael Winter

VK said:
Using intrinsic events forces you to use the non-documented EVENT
object in FF
Click to expand...

Whilst I've never seen explicit documentation (more implication than
anything else), both Netscape's JavaScript Guide and Mozilla's DOM
Reference contain an example (different in each case) that uses the 'event'
identifier in the context of an intrinsic event attribute. In addition,
showing the string representation of an intrinsic event property clearly
reveals the presence of an argument named 'event'.

This behaviour is used by every scriptable user agent that follows the
Netscape event model that I've ever encountered. To dismiss overwhelming
empirical evidence just because Netscape didn't bother to state the
behaviour explicitly is quite ridiculous.
(Some people tried to say here that this is some special EVENT and it
has nothing to do by its nature with window.event in IE).
Click to expand...

They are common in that they both provide access to event-related
information. How they are provided is very different.

[snip]
<p onclick="alert(event.target)">Test</p>
[snip]

Click and get it. I did not create this EVENT object [...]
Click to expand...

No, the user agent did. When the attribute is encountered, it is converted
into an anonymous function internally. Using the Netscape event model, this
is exactly equivalent to:

pElement.onclick = function(event) {
alert(event.target)
};

You can see this representation (excluding the assignment itself) by showing
the toString value, as I stated above.

<p onclick="alert(this.onclick);">Test</p>

will display:

function(event) {
alert(this.onclick);
}

Why is this so difficult to comprehend?
Thus it's a global public self-updating event object.
Click to expand...

That's a leap which you cannot support. If true, one could write:

function myListener() {
alert(event.target);
}

<p onclick="myListener();">Test</p>

and still examine the event object, but you can't outside the IE event
model. The identifier is a formal argument of a function object created by
the user agent. It is not a global.

[snipped nonsense]

Mike
 
M

Michael Winter

Andy LW wrote:

[snip]
could you please explain this line (or point to some online source that
could help me understand [an if statement]
Click to expand...

Essentially, the expression gets a reference to the event target, and checks
that this target is a list item (LI) element. I'll walk through it in
detail.

document.onclick = function(e) {
var tgt;
if ((e = e || window.event)
Click to expand...

If you've managed to wade through the silliness, you will hopefully have
grasped that there are basically two event models: Netscape and IE.

The Netscape model passes the event object to a listener as an argument,
whilst IE provides a global object. So, the first thing we need to do is
get this object in one place. The expression

(e = e || window.event)

is fairly simple. The logical OR operator evaluates its operands as
booleans. If the first operand evaluates to true, the /value/ of that
operand will be the result. If the first operand evaluates to false, the
value of the second operand will be the result. In other words, if e is not
an object reference, replace its value with that of window.event.
&&
Click to expand...

Before moving on to the next expression, we need to make sure that e
actually contains an event object. To do this, we use the logical AND
operator to ensure that all of the expressions in the if statement evaluate
to true.
(tgt = e.srcElement || e.target)
Click to expand...

As part of the difference in event models, both use a different property to
refer to the target of an event. The Netscape/W3C model uses target, whilst
IE uses srcElement. The tgt variable will be assigned one of these
values...
&& /LI/i.test(tgt.nodeName))
Click to expand...

Finally, this regular expression checks the nodeName property of the event
target. The nodeName property contains the tag name for elements (and other
values for other node types). We want to ensure that the event was
targeting a list item (LI), so the expression makes sure that the node name
contains this value.

The regular expression contains the i (case-insensitive) flag. The reason
for this is that the nodeName value can vary depending on whether a
document is HTML or XHTML. With HTML (and XHTML served as HTML), a tag name
(like LI) is always uppercase, and values for other node types (like #text)
are lowercase. With XML-based documents (namely XHTML), the nodeName value
uses the case of the element as XML, unlike SGML, is case-sensitive. This
means that elements borrowed from HTML (like P, TABLE, etc.) are always
lowercase, elements defined in other namespaces may vary. Using a
case-insensitive comparison sidesteps all of this.

I hope that made sense.

Mike
 
R

RobG

VK said:
Using intrinsic events forces you to use the non-documented EVENT
object in FF (Some people tried to say here that this is some special
EVENT and it has nothing to do by its nature with window.event in IE).
Click to expand...

Not documented? A quick search of the Mozilla site yielded:

<URL:http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/guide/evnt.html>

<URL:http://www.mozilla.org/docs/dom/domref/examples.html#999002>

<URL:http://www.mozilla.org/docs/dom/domref/examples8.html>

<URL:http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event>

You have yet to show any evidence that coding events inline is more
'unstable' than adding them dynamically. Adding events dynamically is
more aligned with 'best practice', but that is not the point. Adding
events inline does not 'force' you to use the event object, nor is it
'unstable'.

The difference is that with IE the event object is global, with Mozilla
it is local and therefore you have to access it differently - for the
vast majority of scripts, you don't need to bother with it at all.
<html>
<head>
<title>Event</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>
<body>
<p onclick="alert(event.target)">Test</p>
</body>
</html>

Click and get it. I did not create this EVENT object, nevertheless it's
Click to expand...

Have a look at the properties of an HTML element's style object. You
didn't 'create' them, yet they are there. They are accessible on every
element, but they aren't global.

<p id="x">This is a paragraph</p>
<p id="y"></p>
<script type="text/javascript">
var x = document.getElementById('x');
var z = [];
for (prop in x.style){
z.push( prop + ': ' + ( x.style[prop] || '&nbsp;<i>not set</i>' ) );
}
document.getElementById('y').innerHTML = z.join('<br>');
available and self-updating. Thus it's a global public self-updating
event object.
Click to expand...

No, in the Mozilla model it's a local object belonging to each event.
Thus it's equal to windows.event in IE.
Click to expand...

In my mind it's equivalent to, not equal to.

[...]
 
V

VK

Not documented? A quick search of the Mozilla site yielded:
<URL:http://www.mozilla.org/docs/do­m/domref/examples.html#999002>
<URL:http://www.mozilla.org/docs/do­m/domref/examples8.html>
Click to expand...
<URL:http://www.w3.org/TR/DOM-Level­-2-Events/events.html#Events-E­vent>

Did you actually read these docs or just checked for presence of the
word "Event"? We are not talking about "Event" as a conceptual
definition, we are talking about THAT event, which is in <...
onclick="alert(event.target)">
Taking this into account, read these docs once again. And don't forget
the main one:
<http://www.mozilla.org/docs/dom/domref/dom_event_ref.html#998197>

If you find anything about THAT event, send me your PanPal acc#, I owe
you 10 bucks.
 
V

VK

Thus it's a global public self-updating event object.
That's a leap which you cannot support.
Click to expand...

Actually I can ;-) This object is just a little bit under-done, and for
more confusion is hidden under a bunch of university terms.
Try this in FF:
....
function test() {
var obj = document.getElementById('p1');
alert(obj.onclick.arguments[0].currentTarget.innerHTML);
}
....
<p id="p1" onclick="test2()">Click me</p>
....

All they had to do: make an anonymous forwarding of event reference (as
arguments[0]) to the event handler. They already did it for the event
capturer, so having said "A" say "B" also. So we would not need to use
this sidewalk, and we would have a full equivalent of IE scheme. OK,
methods are called differently, but we are living with it since the
beginning of times.
Why is this so difficult to comprehend?
Click to expand...
It IS difficult to comprehend: the 'event' you can learn only from the
street, the "Russian hills rider" from the official docs, and a bunch
of details which are not covered or covered wrongfully. I'm maybe not
the smartest one here, but still BS in linguistics... It took nearly 5
days of intensive reading and posting to get the picture clear.
 
M

Michael Winter

Actually I can ;-)
Click to expand...

No, you can't (and haven't). In the Netscape/W3C model, the event object
is local, not local. It could be a single object that is altered when
passed between elements, but it doesn't have to be, so 'self-updating'
doesn't necessarily apply, either. As for 'public', I'm not quite sure
what you're trying to imply. It's as public as any local variable can be.

[snip]
function test() {
var obj = document.getElementById('p1');
alert(obj.onclick.arguments[0].currentTarget.innerHTML);
}
...
<p id="p1" onclick="test2()">Click me</p>
Click to expand...

What do you think that proves, aside from the fact that deprecated usage
of the arguments object is still supported? The behaviour has nothing to
do with the involvement of the event object:

function a() {
b();
}
function b() {
alert(a.arguments[0]);
}

a('some value');

You're simply accessing the arguments object as a property of some
function within the execution context stack - a feature which is not
specified in ECMA-262 3rd Ed.

[snip]
Why is this so difficult to comprehend?
Click to expand...

It IS difficult to comprehend: the 'event' you can learn only from the
street [...]
Click to expand...

There will have been examples and articles produced for the past decade,
or so, which demonstrate the usage that's been described. It's been
around from at least NN4; possibly earlier. I agree that it should have
been included in some 'official' documentation, but it hasn't. If you're
that concerned, talk to the Mozilla documentation team and get them to
describe it in their Web Developer section.

[snip]

Mike
 
V

VK

If anyone is still watching this thread:
A week ago I took a small tech-writing gig for a DLL library. That put
me "face down" to the background life of all this stuff.

I have to admit that my "public self-updating event object" is
total bs (and unlike the science degree, this "bs" is all in small
letters and staying from other famous words :-(

Michael Winter tried to explain this to me, but I did not get it.

There is no "public self-updating event object" neither in IE, nor
in FF, nor in any other browser.
There is unique Event object, that acts almost exactly like the Date
object.
The Date object is always "ticking" counting milliseconds. If we do
new Date(), the Date object creates a copy of itself with the
"timestamp" of the moment of the creation. We receive a reference
on this copy for further work. Evidently the original and the copy are
equal to each other, but just one millisecond later they are not (the
Date keeps ticking, the timestamp is frozen).

The Event object is continuously changing, passing through itself all
incoming events. At the moment of any event it checks for registered
event listeners of this particular event type. If there is at least
one, then the Event creates a momentary copy of itself, we could call
it "eventstamp". This "eventstamp" is being delivered to each
listener in some predefined order. There only 3 differences between IE
and FF:

1. Event delivery goes down->up in IE and up->down->up in FF (double
pass).

2. In IE eventstamp appears as automatically created variable
"event" in the body of the function.
In FF eventstamp appears as the first argument of the function, also in
intrinsic functions this argument as always called "event". In
regular functions you can call it however you want.

3. In IE the "event" variable is created automatically for the
outer function as well as for all inner functions. In FF you have to
save needed event properties right away, or access them in indirect way
like outerFunction.arguments[0].someEventProperty.

How does it really work - just in case if you are still curious (I
was). On the source code level there is a Message Dispatcher. It
receives messages (events) from the OS and forms the messages queue.
From that queue it takes the oldest one and goes to the special table,
Click to expand...
where the program keeps all registered message receivers. Program sends
messages to these receivers one-by-one in the predefined order, based
on some receivers properties.
 
L

Lasse Reichstein Nielsen

VK said:
There is no "public self-updating event object" neither in IE, nor
in FF, nor in any other browser.
Click to expand...

Indeed. If you check what happens in IE, there is a global "event"
variable. Its content changes when new events are triggered, meaning
it is a new event object each time.
There is unique Event object, that acts almost exactly like the Date
object.
Click to expand...

There is no global variable called "Event" in IE, although I believe
there is in Gecko-based browsers. There it can be used as a constructor
function for event objects ... something like Date for date objects, yes.
The Date object is always "ticking" counting milliseconds. If we do
new Date(), the Date object creates a copy of itself with the
"timestamp" of the moment of the creation.
Click to expand...

Uhm, no.
The Date object is a single function object. It does nothing by itself.

When you create a new object based on the Date function, the new
object inherits methods from Date.prototype. It is also assigned a
value that is the current time, as reported by the operating system
(the Date function is a host object, so it can access non-Javascript
resources).
We receive a reference on this copy for further work. Evidently the
original and the copy are equal to each other, but just one
millisecond later they are not (the Date keeps ticking, the
timestamp is frozen).
Click to expand...

No, they are even different types.

The date object created is an object. The Date function is (duh :) a
function. Test it:
alert([typeof Date, typeof new Date()]);

The Date function os more like a template, while the date object is a
real object created from the mold of the template. They are no more
equal than a cooike and a cookie cutter.
The Event object is continuously changing, passing through itself all
incoming events. At the moment of any event it checks for registered
event listeners of this particular event type. If there is at least
one, then the Event creates a momentary copy of itself, we could call
it "eventstamp". This "eventstamp" is being delivered to each
listener in some predefined order.
Click to expand...

More likely: the browser is internally listening for input events from
the operating system. When applicable, it converts those events to DOM
events (an OS mouse click to a DOM "click" event). The browser creates
new DOM event objects as needed.
There only 3 differences between IE
and FF:

1. Event delivery goes down->up in IE and up->down->up in FF (double
pass).
Click to expand...

Sounds correct. The Gecko engine uses the W3C DOM 2 Events model. IE
uses their own "bubbling" model (which predates DOM 2, so they were
probably an inspiration to DOM 2 Events).
2. In IE eventstamp appears as automatically created variable
"event" in the body of the function.
Click to expand...

No. The current event is assigned to a global variable called "event"
before bubbling starts. The variable is not local to the body of the
function.
In FF eventstamp appears as the first argument of the function, also in
intrinsic functions this argument as always called "event". In
regular functions you can call it however you want.
Click to expand...

Correct (where "intrinsic functions" are the JS functions created by
the browser from the HTML intrinsic event handler attributes).
3. In IE the "event" variable is created automatically for the
outer function as well as for all inner functions.
Click to expand...

It's a global variable, so it's visible everywhere, except when
shadowed by a local variable with the same name.
In FF you have to
save needed event properties right away, or access them in indirect way
like outerFunction.arguments[0].someEventProperty.
Click to expand...

Not a recommende way of accessing parameters of a function. It doesn't
work well with recursive functions, and it's not part of the ECMAScript
standard.
How does it really work - just in case if you are still curious (I
was). On the source code level there is a Message Dispatcher. It
receives messages (events) from the OS and forms the messages queue.
Agree.

From that queue it takes the oldest one and goes to the special table,
where the program keeps all registered message receivers. Program sends
messages to these receivers one-by-one in the predefined order, based
on some receivers properties.
Click to expand...

Vague, so probably correct :)

/L
 
V

VK

There is no global variable called "Event" in IE, although I believe
there is in Gecko-based browsers.

Should we say "There is an event dispatcher in all browsers that..."
This way we are escaping a confusion between the Event as a programming
term definition (like Function, Subroutine, Loop etc) and some real
entity.
The current event is assigned to a global variable called "event"
Click to expand...
before bubbling starts.

Don't agree. It is rather simple to recreate a situation when we are
handling several events at once (say drag and mousemove). It would mean
that we have 2 global vars with the same name and different values
(nonsense). Actually Microsoft says the same on their usual baby-talk:
"The event object is available only during an event-that is, you can
use it in event handlers but not in other code".
<http://msdn.microsoft.com/library/d.../author/dhtml/reference/objects/obj_event.asp>
So the eventstamp "event" acts as private variable: generic to the
event handler and its inner functions.

outerFunction.arguments[0].som­eEventProperty.
Click to expand...
Not a recommende way
Click to expand...

Just thinking off a way to work with intrinsic event handler having
some arguments to pass to other function:

<div onclick="f1(arg0,arg1,arg3)"> - no problem with IE, but in FF arg0
must be sacrificed to event/event property. It is not very convenient
to reserve first argument in each function for e, just in case if it
will be called from an intrinsic event handler.
?
 

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

Similar Threads

Working on mobile css menu with plenty of frustration! 2
<ul>s nested in <li>s - how to get the on on higher level ? 3
How to change star rating color on mouseenter, on mouseout, and on onclick 0
Help with my responsive home page 2
How can I hide a div using an event listener on multiple checkboxes? 6
onmouseleave event in IE 3
cross browser display block none 2
CSS Resize problem 4

Members online

No members online now.
Total: 29 (members: 1, guests: 28)
Robots: 233

Forum statistics

Threads
473,774
Messages
2,569,598
Members
45,160
Latest member
CollinStri

Latest Threads

Top