From: William Wallace on
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?
From: Thomas 'PointedEars' Lahn on
William Wallace wrote:

> 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
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: William Wallace on
On Jul 20, 12:01 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> William Wallace wrote:
> > 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).

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.

> > 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.

It's my only option.

> > So, are the two completely interchangeable on the top 5 browsers?
>
> 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+.
From: Gregor Kofler on
Am 2010-07-20 12:29, William Wallace meinte:
> On Jul 20, 12:01 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de>

>>> So, are the two completely interchangeable on the top 5 browsers?
>>
>> Of course not, whatever you think "the top 5 browsers" are.
>
> The top 5 browsers are...

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

Gregor


--
http://www.gregorkofler.com
From: David Mark on
On Jul 20, 4:46 am, William Wallace <wbravehea...(a)googlemail.com>
wrote:
> 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.