Event Listeners : window vs document

[William Wallace]

I can't find a definite answer anywhere on when's the right time to
use window. and when is the right time to use document. when it comes
to prefixing a call to addEventListener or attachEvent.

I've seen people using window.addEventlistener for onload, mouse
events and I've seen others using document.addEventListener for those
same things. I can see how some appear to be more obvious, like DOM
events such as node inserted events - they'd definitely have a strong
argument for being document.addEventListener.

So, are the two completely interchangeable on the top 5 browsers?

 

[Thomas 'PointedEars' Lahn]

I can't find a definite answer anywhere on when's the right time to
use window. and when is the right time to use document. when it comes
to prefixing a call to addEventListener or attachEvent.

"Prefixing a call"? Learn the basics first, please.

I've seen people using window.addEventlistener for onload,

That would be wrong. If anything, window.addEventListener() could be used
for the _load_ event, as an alternative to the proprietary `onload' event-
handler property of the object referred to by `window'. Neither is
generally recommended, though; use the `onload' attribute of the `body'
element instead.

mouse events

If the mouse event pertains to the window instead of the document, why not.
Otherwise it is either inefficient (the mouse event needs to bubble up one
level more) or in most cases just wrong (non-bubbling events will never
reach the window, and although capturing events could reach the window
before all other objects, that could easily interfere with the browser UI,
if they are even supported).

and I've seen others using document.addEventListener for those same
things.

Dynamically adding event listeners is being heavily overrated, and over-used
these days, thanks to all that "Unobtrusive JavaScript" nonsense going
around.

I can see how some appear to be more obvious, like DOM
events such as node inserted events - they'd definitely have a strong
argument for being document.addEventListener.

Don't make guesses, read the W3C DOM Level 2+ Event Specifications where the
`addEventListener' method is defined. Then you will find out that the
object needs to implement the EventTarget interface in order to have that
method, and that not all events apply to all objects. Then you read the
documentation for the relevant DOM implementation (e.g., the Gecko DOM), and
see which events are supported for which type of object. Then you define
feature tests with branches in your code, enabling you to decide *at
runtime* which approach to use for which environment.

So, are the two completely interchangeable on the top 5 browsers?

Of course not, whatever you think "the top 5 browsers" are.


PointedEars

 

[William Wallace]

If the mouse event pertains to the window instead of the document, why not.
Otherwise it is either inefficient (the mouse event needs to bubble up one
level more) or in most cases just wrong (non-bubbling events will never
reach the window, and although capturing events could reach the window
before all other objects, that could easily interfere with the browser UI,
if they are even supported).

So can we say then that a simple rule is if I want to add an event
listener for load, unload and mouse events, then I should always use
document rather than window? They're the only events I'm interested
in.

Dynamically adding event listeners is being heavily overrated, and over-used
these days, thanks to all that "Unobtrusive JavaScript" nonsense going
around.

It's my only option.

Of course not, whatever you think "the top 5 browsers" are.

The top 5 browsers are IE, Firefox, Opera, Chrome and Safari. When it
comes to versions that are pretty much dead these days, I'm only
interested in IE6+, Firefox 2+, Opera 9+, Chrome 4+ and Safari 3+.

 

[Gregor Kofler]

Am 2010-07-20 12:29, William Wallace meinte:

On Jul 20, 12:01 pm, Thomas 'PointedEars' Lahn<[email protected]>

The top 5 browsers are...

....whatever. As Thomas stated: They are not interchangeable.

Gregor

 

[David Mark]

I can't find a definite answer anywhere on when's the right time to
use window. and when is the right time to use document. when it comes
to prefixing a call to addEventListener or attachEvent.

I've seen people using window.addEventlistener for onload, mouse
events and I've seen others using document.addEventListener for those
same things.

Using window for load is the same as using body for load. People use
window because either their script in is in the head (and therefore
the body is unavailable) or they are simply copying code without
understanding (a very popular strategy).

As for attaching mouse-related listeners to the window, that
definitely indicates ignorance on the part of the authors.

I can see how some appear to be more obvious, like DOM
events such as node inserted events - they'd definitely have a strong
argument for being document.addEventListener.

There's no standard for the window object (certainly nothing that says
it must feature an addEventListener method). So you should avoid
using it whenever possible (virtually always).

So, are the two completely interchangeable on the top 5 browsers?

I assume you mean in every configuration of every revision of the
desktop versions IE, FF, Opera, Safari and Chrome. Even if you could
prove that to be the case, why would you care? There are a lot more
than 5 browsers out there and if you aren't prepared to do a lot of
(possibly impossible) feature testing in your code, you won't be able
to provide useful degradation paths for the rest. Better to
understand the underlying abstractions than to observe 5 browsers.

 

[Thomas 'PointedEars' Lahn]

Using window for load is the same as using body for load.

No, it is not. That is one major reason why the `window.onload' approach is
flawed.


PointedEars

 

[David Mark]

No, it is not.  That is one major reason why the `window.onload' approach is
flawed.

Okay, technically speaking, it works the same when it works, which is
less often than one could expect the standard body approach to do.