Events

[disappearedng]

Hi everyone
I am currently confused about a piece of code that I have encountered:

function handleKeyUp(e){

e = (!e) ? window.event : e; //get the event
target = (!e.target) ? e.srcElement : e.target; //get the event's
target
if (target.nodeType == 3)
target = target.parentNode;

if (e.charCode)
code = e.charCode;
else
if (e.keyCode)
code = e.keyCode;
else
if (e.which)
code = e.which;
else
code = 0;

if (e.type == "keyup") {
isKeyUpDownPressed = false;

1) Is e here an event?
2) what's the purpose of e = (!e) ? window.event : e; //get the event
3) What's if (target.nodeType == 3)
target = target.parentNode;'
4) What does this piece of code do?

 

[Gregor Kofler]

disappearedng meinte:

Hi everyone
I am currently confused about a piece of code that I have encountered:

function handleKeyUp(e){

	e = (!e) ? window.event : e; //get the event[/QUOTE]

e = e || window.event;
[QUOTE]
target = (!e.target) ? e.srcElement : e.target; //get the event's[/QUOTE]

target = e.target || e.srcElement;
[QUOTE]
target
	if (target.nodeType == 3)
		target = target.parentNode;

	if (e.charCode)
		code = e.charCode;
	else
		if (e.keyCode)
			code = e.keyCode;
		else
			if (e.which)
				code = e.which;
			else
				code = 0;

	if (e.type == "keyup") {
		isKeyUpDownPressed = false;

1) Is e here an event?
2) what's the purpose of e = (!e) ? window.event : e; //get the event

e = e || window.event; will suffice.
If e is falsy (e.g. undefined), e will get a reference to window.event.
A necessity due to different event models in the various browser DOMs.

3) What's if (target.nodeType == 3)
target = target.parentNode;'

What it says: If the nodeType of the element that received the event is
3 (a text node), target will be re-assigned to the parentNode (normally
an element node).

4) What does this piece of code do?

A keyup listener, that tries to assign event target and key code to
global variables. And then another variable isKeyUpDownPressed is set to
false.
That's it. Pretty bad code and style.

Gregor

 

[Thomas 'PointedEars' Lahn]

disappearedng meinte:

I am currently confused about a piece of code that I have encountered:

function handleKeyUp(e){

	e = (!e) ? window.event : e; //get the event[/QUOTE]

e = e || window.event;[/QUOTE]

if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}

if (e)
{
// ...
}
[QUOTE]
target = e.target || e.srcElement;[/QUOTE]

*and*

if (target)
{
// ...
}
[QUOTE]
e = e || window.event; will suffice.[/QUOTE]

It won't.
[QUOTE]
If e is falsy (e.g. undefined), e will get a reference to window.event.[/QUOTE]

Iff type-converting that value to boolean does not throw an exception.
[QUOTE]
A necessity due to different event models in the various browser DOMs.[/QUOTE]

A beginning for handling that.


PointedEars

 

[slebetman]

function handleKeyUp(e){
e = (!e) ? window.event : e; //get the event
target = (!e.target) ? e.srcElement : e.target; //get the event's

1) Is e here an event?
2) what's the purpose of e = (!e) ? window.event : e; //get the event

e here is the event object. Regular browsers will pass the event
object as the first argument to the event handler. Hence the
'handleKeyUp(e)' bit of code. But IE does it differently. It doesn't
pass anything to the event handler (which makes e undefined) instead
IE implements the event object as a global variable. Hence the
'window.event' thing. So, the code is checking to see if e is
'falsy' (and undefined IS falsy) and if it is, assign window.event to
e, otherwise assign e back to itself. Alternative ways to write this
are:

/* if e is falsy then e is window.event */
if (!e) {
e = window.event;
}

or my preferred way to write this

/* e is e or window.event */
e = e || window.event;

or some may even prefer

/* if e is undefined then e is window.event */
if (e == undefined) {
e = window.event;
}

3) What's if (target.nodeType == 3)
target = target.parentNode;'

Some browsers, particularly Webkit based browsers like Safari and
Nokia's web browser for the S60 platform sometimes triggers the event
on the text node rather than the node containing the text node. This
is not typically what you'd want. What you'd typically want is to know
which <div> or <span> or <p> etc. is associated with the event. So if
we get a text node (nodeType 3) the real node we're interested in
would be its parent node.

 

[Thomas 'PointedEars' Lahn]

e here is the event object. Regular browsers will pass the event object
as the first argument to the event handler.
s/Regular/Standards-compliant/

Hence the 'handleKeyUp(e)' bit of code. But IE does it differently. It
doesn't pass anything to the event handler (which makes e undefined)
instead IE implements the event object as a global variable.

No, it makes `event' a *property* of a Window object, which is in the scope
chain, to store a reference to an Event object.


PointedEars

 

[Gabriel Gilini]

No, it makes `event' a *property* of a Window object, which is in the scope
chain, to store a reference to an Event object.

It's probably a very obvious answer, but you can guess that I'm new at
this.

I don't know if I'm missing the point here. Saying that it isn't a
global var but instead a property of the window object is 'only' a
conceptual mistake, right? I mean, the window's properties behave
pretty much like global vars, don't they?

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Cheers

Gabriel Gilini

 

[Lasse Reichstein Nielsen]

disappearedng meinte:

I am currently confused about a piece of code that I have encountered:

function handleKeyUp(e){

	e = (!e) ? window.event : e; //get the event[/QUOTE]

e = e || window.event;[/QUOTE]

if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}[/QUOTE]

Why bother?
If window doesn't exist, then I'd be willing to let the code fail
visibly. Something is so screwed up anyway, that I see no reason
to fail gracefully.
If window.event doesn't exist, then
e = e || window.event;
will assign undefined to e, which is just as good as null.
[QUOTE]
if (e)
{
// ...
}[/QUOTE]

Again, if the above doesn't give us an event, then we are in a
non-standard compliant setting that we haven't ever heard of before.
Anybody creating a new non-standard compliant and non-IE compatible
setting deserves to see crashes.
[QUOTE]
It won't.[/QUOTE]

For practical use, I'd say it would. Can you give a non-theoretical
example where it would fail?
[QUOTE]
Iff type-converting that value to boolean does not throw an exception.[/QUOTE]

That is possible. After all, it's a host object, so it can do anything.

/L

 

[Thomas 'PointedEars' Lahn]

disappearedng meinte:
I am currently confused about a piece of code that I have encountered:

function handleKeyUp(e){

	e = (!e) ? window.event : e; //get the event
e = e || window.event;[/QUOTE]
if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}[/QUOTE]

Why bother?[/QUOTE]

Because it just isn't a two-browser or two-DOM world.
[QUOTE]
If window doesn't exist, then I'd be willing to let the code fail
visibly. Something is so screwed up anyway, that I see no reason
to fail gracefully.
If window.event doesn't exist, then
e = e || window.event;
will assign undefined to e, which is just as good as null.[/QUOTE]

From the event object reference not being passed as `e' does not follow that
`window.event' is viable.
[QUOTE]
Again, if the above doesn't give us an event, then we are in a
non-standard compliant setting that we haven't ever heard of before.
Anybody creating a new non-standard compliant and non-IE compatible
setting deserves to see crashes.[/QUOTE]

It is a really Bad Idea to try blaming users for the mistakes of the vendors
of their software.  It is one thing not to support something; it is another
to break it willingly.
[QUOTE]
For practical use, I'd say it would. Can you give a non-theoretical
example where it would fail?[/QUOTE]

No, but I rather program defensively now instead of having to deal with code
that breaks something somewhere later.  Having bugs reported (which can also
be done in an automated way) is an entirely different animal than actually
embracing them.


PointedEars

 

[Thomas 'PointedEars' Lahn]

No, it makes `event' a *property* of a Window object, which is in the
scope chain, to store a reference to an Event object.

[...] I don't know if I'm missing the point here. Saying that it isn't a
global var but instead a property of the window object is 'only' a
conceptual mistake, right?

Such theoretical misconceptions can lead to very practical problems.
I/We have seen and discussed this numerous times before.

I mean, the window's properties behave pretty much like global vars,
don't they?

They don't. For one thing, provided the Window host object can be augmented
with user-defined properties (which should not be assumed), such properties
can be deleted. Global variables, as properties of the Global Object that
have the DontDelete attribute, can't.

This also isn't really news, and can (and should) readily be researched
before asking about it here again.

Please trim your quotes as observed here, and as described in the FAQ.

<http://jibbering.com/faq/#posting>


PointedEars

 

[Gabriel Gilini]

They don't.  For one thing, provided the Window host object can be augmented
with user-defined properties (which should not be assumed), such properties
can be deleted.  Global variables, as properties of the Global Object that
have the DontDelete attribute, can't.

I see. Thank you for that.

This also isn't really news, and can (and should) readily be researched
before asking about it here again.

Please trim your quotes as observed here, and as described in the FAQ.

<http://jibbering.com/faq/#posting>

And sorry about this.

Cheers

Gabriel Gilini

 

[dhtml]

disappearedng meinte:
I am currently confused about a piece of code that I have encountered:

function handleKeyUp(e){

	e = (!e) ? window.event : e; //get the event
e = e || window.event;[/QUOTE]
if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}[/QUOTE]

Why bother?[/QUOTE]

Really.

The error condition will occur if testing in a non-browser environment.
That is not the case here.
[QUOTE]
If window doesn't exist, then I'd be willing to let the code fail
visibly. Something is so screwed up anyway, that I see no reason
to fail gracefully.[/QUOTE]

Yep.

Exit silently if window is undefined is a horrible way to handle that
error condition. Instead, a script error "window is undefined" would
indicate that (if it ever happened). This error will happen naturally,
should someone declare a window variable:-

function broken(){
var window;
window.alert();
}

The error that would occur is a much better alternative to silent
failure. Let the error occur, look at the stack and find the root cause.

Garrett

 

[Thomas 'PointedEars' Lahn]

Exit silently if window is undefined is a horrible way to handle that
error condition.

Not doing anything is better than breaking something.

Instead, a script error "window is undefined" would indicate that (if it
ever happened). This error will happen naturally, should someone declare
a window variable:-

function broken(){ var window; window.alert(); }

The error that would occur is a much better alternative to silent
failure. Let the error occur, look at the stack and find the root cause.

You miss the point. Users are not capable of debugging or understanding any
of the technobabble in the first place. So they will hold you (or your
customer) responsible for writing a bad program/making a bad Web site.


PointedEars