document.addEventListener over window.addEventListener
William Wallace
document.attachEvent for the following events?
load, unload, resize, scroll and mousemove.
Erwin Moller
> Am I right in thinking that I want to use document.addEventListener /
> document.attachEvent for the following events?
>
> load, unload, resize, scroll and mousemove.
Hard to tell.
You can also do it like this:
<body onLoad="whatever();" onUnLoad="whatever2();">
Why do you want to use addEventListener ?
If you give more context, the good people in here can give you better
advise.
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
William Wallace
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> William Wallace schreef:
>
> > Am I right in thinking that I want to use document.addEventListener /
> > document.attachEvent for the following events?
>
> > load, unload, resize, scroll and mousemove.
>
> Hard to tell.
>
> You can also do it like this:
>
> <body onLoad="whatever();" onUnLoad="whatever2();">
>
> Why do you want to use addEventListener ?
> If you give more context, the good people in here can give you better
> advise.
I'm doing everything from an included JS file, so I don't get to
determine what's in the body tag. I find that on this group, the less
context given the better. They just pick apart everything you say if
you give more detail.
Erwin Moller
Ok, but what is your question then?
This is what you wrote:
--------------------------------------------
Am I right in thinking that I want to use document.addEventListener /
document.attachEvent for the following events? load, unload, resize,
scroll and mousemove.
--------------------------------------------
Is your question if addEventListener() and attachEvent() can add the
named events?
Is your question if there are more methods to add events?
Is your question what browsers support those methods?
Is your question if there are other methods to add eventListeners?
Do you wonder how to use these methods from your JavaScript file?
etc.
So many possibilities. Do you see why I ask?
Anyway: I learned a lot from the following articles:
http://www.quirksmode.org/js/introevents.html
http://www.quirksmode.org/js/events_advanced.html
No doubt somebody will claim that the above articles suck. ;-)
William Wallace
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> William Wallace schreef:
> > On Jul 20, 5:00 pm, Erwin Moller
> > <Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> >> William Wallace schreef:
>
> >>> Am I right in thinking that I want to use document.addEventListener /
> >>> document.attachEvent for the following events?
> >>> load, unload, resize, scroll and mousemove.
> >> Hard to tell.
>
> >> You can also do it like this:
>
> >> <body onLoad="whatever();" onUnLoad="whatever2();">
>
> >> Why do you want to use addEventListener ?
> >> If you give more context, the good people in here can give you better
> >> advise.
>
> > I'm doing everything from an included JS file, so I don't get to
> > determine what's in the body tag. I find that on this group, the less
> > context given the better. They just pick apart everything you say if
> > you give more detail.
>
> Ok, but what is your question then?
Here it is again:
Am I right in thinking that I want to use document.addEventListener /
document.attachEvent for the following events?
load, unload, resize, scroll and mousemove.
> This is what you wrote:
> --------------------------------------------
> Am I right in thinking that I want to use document.addEventListener /
> document.attachEvent for the following events? load, unload, resize,
> scroll and mousemove.
> --------------------------------------------
Yes - that's it. I want to know if I should be attaching the events to
document or window for each of those events. I can't find that info
anywhere. I tried asking in another thread and as usual on this forum
the first responses just want to pick apart the question rather than
just answering it.
> Is your question if addEventListener() and attachEvent() can add the
> named events?
No. I know they can. I just want to know if I use document or window.
> Is your question if there are more methods to add events?
> Is your question what browsers support those methods?
> Is your question if there are other methods to add eventListeners?
> Do you wonder how to use these methods from your JavaScript file?
> etc.
No, No, No and No.
> So many possibilities. Do you see why I ask?
Not really.
> Anyway: I learned a lot from the following articles:
>
> http://www.quirksmode.org/js/introevents.htmlhttp://www.quirksmode.org/js/events_advanced.html
>
> No doubt somebody will claim that the above articles suck. ;-)
I wouldn't say they suck, but they didn't have an answer to my
question. Just all the info I already know.
David Mark
wrote:
> On Jul 20, 6:07 pm, Erwin Moller
>
>
>
>
>
> <Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> > William Wallace schreef:
> > > On Jul 20, 5:00 pm, Erwin Moller
> > > <Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> > >> William Wallace schreef:
>
> > >>> Am I right in thinking that I want to use document.addEventListener /
> > >>> document.attachEvent for the following events?
> > >>> load, unload, resize, scroll and mousemove.
> > >> Hard to tell.
>
> > >> You can also do it like this:
>
> > >> <body onLoad="whatever();" onUnLoad="whatever2();">
>
> > >> Why do you want to use addEventListener ?
> > >> If you give more context, the good people in here can give you better
> > >> advise.
>
> > > I'm doing everything from an included JS file, so I don't get to
> > > determine what's in the body tag. I find that on this group, the less
> > > context given the better. They just pick apart everything you say if
> > > you give more detail.
>
> > Ok, but what is your question then?
>
> Here it is again:
>
> Am I right in thinking that I want to use document.addEventListener /
> document.attachEvent for the following events?
>
> load, unload, resize, scroll and mousemove.
For load and unload, it depends on the context (i.e. is the body
available). For resize and scroll, I believe attaching to window is
the most compatible (and makes logical sense). For mousemove,
definitely not.
William Wallace
> > Am I right in thinking that I want to use document.addEventListener /
> > document.attachEvent for the following events?
>
> > load, unload, resize, scroll and mousemove.
>
> For load and unload, it depends on the context (i.e. is the body
> available). For resize and scroll, I believe attaching to window is
> the most compatible (and makes logical sense). For mousemove,
> definitely not.
Thanks a lot David. Now we're getting somewhere :) The body is
definitely available. So I've now got my list of whether to use window
or document.
Use window.* for resize/scroll events.
Use document.* for all mouse events and load/unload.
It's part of something for a corporate website, there's nobody showing
up with IE4 or Netscape 6. It's basically just the most recent few
versions of IE, FF, Chrome, Safari and Opera. Not that I'm doing
useragent sniffing or anything, I'm just saying what my test range is.
I'll be doing feature testing. The problem I found is that feature
testing didn't tell me whether I should prefer window or document
because both had the add/remove EventListener (or attach/detach Event
for IE).
David Mark
wrote:
> On Jul 20, 8:16 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > Am I right in thinking that I want to use document.addEventListener /
> > > document.attachEvent for the following events?
>
> > > load, unload, resize, scroll and mousemove.
>
> > For load and unload, it depends on the context (i.e. is the body
> > available). For resize and scroll, I believe attaching to window is
> > the most compatible (and makes logical sense). For mousemove,
> > definitely not.
>
> Thanks a lot David. Now we're getting somewhere :)
Possibly.
> The body is
> definitely available. So I've now got my list of whether to use window
> or document.
>
> Use window.* for resize/scroll events.
I don't think you can go wrong there. But realize this is not a
standard. You need to detect whether window.addEventListener exists
at all.
>
> Use document.* for all mouse events and load/unload.
No. Use the body for load/unload. And in fact, don't use unload at
all as it breaks fast history navigation (and there's rarely a good
reason to use it anyway).
>
> It's part of something for a corporate website, there's nobody showing
> up with IE4 or Netscape 6.
Hmmm. Is there nobody showing up with Netscape 6 because nobody is
using that browser or because the site breaks in that browser?
Clearly nobody (sane) uses Netscape 6 these days, but do you see the
problem with such (commonly expressed) assumptions?
And if you follow my advice, at least as far as attaching these
listeners goes, you won't have any trouble with those browsers anyway.
> It's basically just the most recent few
> versions of IE, FF, Chrome, Safari and Opera.
What is? Are you reading from usage statistics? See above. :)
> Not that I'm doing
> useragent sniffing or anything,
Good.
> I'm just saying what my test range is.
The last few versions of the above browsers is not necessarily a bad
range. Compared to most Web (and even library) developers it is
admirable. Just be careful of reading too much into positive
results. You have to have some understanding of each and every line
of code to be reasonably sure that it will work in the myriad browsers/
configurations that you did not test.
> I'll be doing feature testing.
Good. In many cases feature detection is all that is needed. Feature
testing comes in to play when features exist but are known to be buggy
in some cases (this is where the libraries typically regress back to
browser sniffing). Taken to an ultra-paranoid extreme you could
assume this about all features. But of course, not all features are
easily testable. It's an imperfect world, but with experience and
good practice, you can approach perfection rather than flirting with
disaster.
> The problem I found is that feature
> testing didn't tell me whether I should prefer window or document
> because both had the add/remove EventListener (or attach/detach Event
> for IE).
This is where experience (and standards) come into play. There is no
standard for window.addEventListener and there are (or at least were)
browsers out there that implement document.addEventLister but not
window.addEventListener. So you should avoid the window version
whenever possible and detect (not test) it before use.
So what if window.addEventListener is missing and you need to listen
for scroll/resize? I would use document.documentElement myself. The
only reason I would not use document.documentElement (or document) for
scroll/resize in the first place is for backward compatibility (ISTM
that some very old browsers and possibly off-brands available today
failed to support scroll/resize listeners on the document object, but
I could be thinking of DOM0).
David Mark
>
> No doubt somebody will claim that the above articles suck. ;-)
>
I don't know if I've read those two in particular, but many of the
explanations given on that site do indeed suck. If it just stuck to
the empirical evidence gathering, it would be a better site.
William Wallace
> Good. In many cases feature detection is all that is needed. Feature
> testing comes in to play when features exist but are known to be buggy
> in some cases (this is where the libraries typically regress back to
> browser sniffing). Taken to an ultra-paranoid extreme you could
> assume this about all features. But of course, not all features are
> easily testable. It's an imperfect world, but with experience and
> good practice, you can approach perfection rather than flirting with
> disaster.
Had to snip a lot of great info. Saved and absorbed. Dude, write a
book, I'll buy a copy. It seems that there are no good books. You
could get Thomas to proof-read it. LOL - that would be fun :)
David Mark
wrote:
> On Jul 20, 9:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Good. In many cases feature detection is all that is needed. Feature
> > testing comes in to play when features exist but are known to be buggy
> > in some cases (this is where the libraries typically regress back to
> > browser sniffing). Taken to an ultra-paranoid extreme you could
> > assume this about all features. But of course, not all features are
> > easily testable. It's an imperfect world, but with experience and
> > good practice, you can approach perfection rather than flirting with
> > disaster.
>
> Had to snip a lot of great info. Saved and absorbed.
Glad I could help.
> Dude, write a
> book, I'll buy a copy.
I get a lot of that. I have been working on a book on-again and off-
again for years. The trouble is that there is not a lot of motivation
as I can make a lot more money writing code than writing about
code. ;)
I suppose if some savvy publisher advanced me, oh, 50K or so, I'd get
right on it. As it is, the one I talked to was in a completely
different neighborhood (one that I prefer to avoid, at least after
dark). :)
> It seems that there are no good books.
You are learning fast. But the publishers see "good books" as books
that will sell the most copies. The representatives I dealt with were
of the opinion that "everyone" is really excited about "these
libraries" (e.g. jQuery). They sent me an outline of one to look at
(and review) and I asked them if it was going to be a children's book
and indicated that the only sort of jQuery book I would consider
writing would be of the contrarian view. I think that and my high
asking price turned them off, but I do still hear from them from time
to time. Maybe some day they will realize that somebody has to take a
chance and publish something fresh. I mean, in five or ten years, who
is going to care about jQuery puff pieces?
> You
> could get Thomas to proof-read it. LOL - that would be fun :)
I think Thomas would make an excellent technical editor for a book on
JS. But fun? :)
Thomas 'PointedEars' Lahn
> On Jul 20, 5:00 pm, Erwin Moller
>> You can also do it like this:
>>
>> <body onLoad="whatever();" onUnLoad="whatever2();">
>>
>> Why do you want to use addEventListener ?
>> If you give more context, the good people in here can give you better
>> advise.
>
> I'm doing everything from an included JS file,
Don't do that, then.
> [...] I find that on this group, the less context given the better. [...]
Are you *really* *really* *very* sure about that?
<http://catb.org/esr/faqs/smart-questions.html#beprecise>
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Hans-Georg Michna
things age so quickly. After a few years every book is outdated.
That limits sales.
Hans-Georg
David Mark
georgNoEmailPle...@michna.com> wrote:
> A general problem with books on actual JavaScript usage is that
> things age so quickly. After a few years every book is outdated.
>
Oh I don't know. JS has been pretty static for over a decade. The
DOM implementations add new features, but I'm still using a lot of
cross-browser code from the turn of the century (most of it originally
written with IE5/NN6 in mind). It's not the browsers, it's the book
authors (who don't understand browsers).
And lately the major browsers have converged to become nearly
indistinguishable (save for added proprietary features). It's the ill-
advised designs of most "cross-browser" libraries that make everything
so hard. That's why they too have very short shelf lives.
Erwin Moller
> Had to snip a lot of great info. Saved and absorbed. Dude, write a
> book, I'll buy a copy.
I second that.
It is annoying to browse through books/websites that contain
misinformation, bad practices, etc.
It is hard to become good at JavaScript/DOM without investing huge
amounts of time into it.
So: Go Mark! Not for the money, do it for the Karma!
David Mark
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> William Wallace schreef:
>
> > Had to snip a lot of great info. Saved and absorbed. Dude, write a
> > book, I'll buy a copy.
>
> I second that.
Thanks Erwin.
> It is annoying to browse through books/websites that contain
> misinformation, bad practices, etc.
Isn't it? :)
> It is hard to become good at JavaScript/DOM without investing huge
> amounts of time into it.
Yes, due to all of the junk out there, it can take a lot of time to
figure out.
>
> So: Go Mark! Not for the money, do it for the Karma!
>
I'll see. I happened to hear from a representative at my prospective
publisher today. I'm trying to work out a deal that will benefit
everyone. Can't do it for the Karma alone though. :)
William Wallace
>
> I'll see. I happened to hear from a representative at my prospective
> publisher today. I'm trying to work out a deal that will benefit
> everyone. Can't do it for the Karma alone though. :)
Well, it looks nice on the CV/Resume too, and gets you exposure and
job offers from unexpected places.
David Mark
wrote:
The problem is that I have my hands full as it is. But occasionally
find time to work on my library (also the source of job offers) and
the book. I've got enough raw material for a whole series of books,
but not enough time to organize it. And for raw material, much of it
is quite fresh (see the primers on my site). :)
williamc
> On Jul 20, 3:55 pm, William Wallace <wbravehea...@googlemail.com>
> wrote:
{snipped]
>> Dude, write a
>> book, I'll buy a copy.
>
> I get a lot of that. I have been working on a book on-again and off-
> again for years. The trouble is that there is not a lot of motivation
> as I can make a lot more money writing code than writing about
> code. ;)
>
> I suppose if some savvy publisher advanced me, oh, 50K or so, I'd get
> right on it. As it is, the one I talked to was in a completely
> different neighborhood (one that I prefer to avoid, at least after
> dark). :)
>
>> It seems that there are no good books.
>
> You are learning fast. But the publishers see "good books" as books
> that will sell the most copies. The representatives I dealt with were
> of the opinion that "everyone" is really excited about "these
> libraries" (e.g. jQuery). They sent me an outline of one to look at
> (and review) and I asked them if it was going to be a children's book
> and indicated that the only sort of jQuery book I would consider
> writing would be of the contrarian view. I think that and my high
> asking price turned them off, but I do still hear from them from time
> to time. Maybe some day they will realize that somebody has to take a
> chance and publish something fresh. I mean, in five or ten years, who
> is going to care about jQuery puff pieces?
LOL. I recently read the new Sitepoint book on JS, (The Art and Science
of JavaScript - one author per chapter), and was thinking how much more
entertaining it would have been if written by the regular posters from
this NG.
My mental title was "The Contrarians' Guide to Javascript".
>> You
>> could get Thomas to proof-read it. LOL - that would be fun :)
>
> I think Thomas would make an excellent technical editor for a book on
> JS. But fun? :)
--
--williamc
David Mark
Depending on which posters, perhaps "The Competent Guide to
Javascript".
Evan Meagher
original response was hilarious! "..less context is better, they just
pick apart what you say."
It's so true.
"Give me more details so I can tell you that you are going about it all
wrong, or that you shouldn't be attempting it at all!"
or even better-
"Why are you trying to do that?"
Classic!
Anyways, regarding your original topic (I know it has since turned into
talk of a book deal), half of the events will only work for window and
half for document.
I was just finishing up an events article on my own site and came upon
this post. For attachEvent in IE (or inline events) you have to use
window for certain events and document for others.
use window for scroll,load,unload,focus,blur, and resize
use document for all mouse/key events, click, and dblclick
Hope that sheds some light on the original question.
http://solidlystated.com
Hardware. Software. Solid.
*** Sent via Developersdex http://www.developersdex.com ***
David Mark
> LOL @ William Wallace. I registered so that I could tell you that your
> original response was hilarious! "..less context is better, they just
> pick apart what you say."
>
> It's so true.
In general, "they" pick apart things that demonstrate faulty thinking.
>
> "Give me more details so I can tell you that you are going about it all
> wrong, or that you shouldn't be attempting it at all!"
If someone is going about something all wrong or attempting the
impossible, it is helpful to let them know. Of course, many people
are looking for magic rather than reasoning.
>
> or even better-
>
> "Why are you trying to do that?"
>
> Classic!
Is this your first time on Usenet? You are going about it all
wrong. :)
>
> Anyways, regarding your original topic (I know it has since turned into
> talk of a book deal), half of the events will only work for window and
> half for document.
Half? Who conducted that study?
>
> I was just finishing up an events article on my own site and came upon
> this post.
> For attachEvent in IE (or inline events) you have to use
> window for certain events and document for others.
It sounds as if your article needs more work.
>
> use window for scroll,load,unload,focus,blur, and resize
>
> use document for all mouse/key events, click, and dblclick
We've been over all of this (in much greater detail).
>
> Hope that sheds some light on the original question.
Doubtful.
Ironic.
> Hardware. Software. Solid.
>
> *** Sent via Developersdexhttp://www.developersdex.com***
Of course. :(
Evan Meagher
solid.
David Mark
> I can't tell what's sarcasm in that and what's not, but the JS is 100%
> solid.
Will you please learn to quote? If you are referring to your last
(first ever?) post here, it contained no JS.
Evan Meagher
David Mark
> Will you please learn not to be a fucking douche? Thanks.
LOL. You broke after two posts? Best to steer clear of Usenet (not
to mention me) from now on.
Dr J R Stockton
>, Sun, 8 Aug 2010 04:08:21, Evan Meagher <evans...@gmail.com> posted:
>Will you please learn not to be a fucking douche? Thanks.
I'd not encourage you to be optimistic there; he evidently believes that
vehemence is an adequate substitute for reasoning.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
David Mark
wrote:
> In comp.lang.javascript message <4c5e2db5$0$2516$815e3...@news.qwest.net
>
> >, Sun, 8 Aug 2010 04:08:21, Evan Meagher <evanssp...@gmail.com> posted:
> >Will you please learn not to be a fucking douche? Thanks.
>
> I'd not encourage you to be optimistic there; he evidently believes that
> vehemence is an adequate substitute for reasoning.
>
Sucking up to one-off losers, doc? Granted you've alienated all of
the regulars with your xenophobic tirades and boundless ego, but the
pairing of you and this neophyte seems unlikely.
And I told that clown to learn to quote. Do you really have a problem
with that or are you just spouting random gibberish? Doesn't take any
"reasoning" to see that he can't quote and needs to learn how.