| home / programming / javascript / events |   [previous] |
|
|
Another common task is finding where the user is in a document. The DOM
returns clientX and clientY from the event
object to tell you where on the display the click or other event came from--but
it doesn't take scrolling into account. You may find that a display
triggered by a user's click is out of sight up there somewhere. Again, I have
a central branching code:
/*
You can call whereAt from any place you need to know the
exact location of an event on the displayed page.
The returned value is a two element array - [x,y].
*/
function whereAt(e){
var positionX=0;
var positionY=0;
if(!e && window.event){ // IE code
positionX= event.clientX+ document.body.scrollTop;
positionY= event.clientY+document.body.scrollTop;
if(document.createDocumentFragment) {
positionY+= document.documentElement.scrollTop;
positionX+= document.documentElement.scrollTop;
}
/*
I have to test IE browsers to see if they use the
document.body or the document.documentElement to control
the scrollbars. I test for IE6+ with the
createDocumentFragment test, which isn't supported in
previous versions. Older IEs scroll the body, new ones
scroll the HTML element
*/
}
else if(window.pageXOffset){ // N6 and Mozilla
positionX= e.clientX+ window.pageXOffset;
positionY= e.clientY+ window.pageYOffset;
}
var posArray=[positionX, positionY];
return posArray;
}Netscape6 and Mozilla look at some special properties they gave the window
object. There is no DOM equivalent for the page being scrolled. Navigator
has its own methods, which I have out back in the hut full of
layers, ActiveX and Java code.
I usually don't call this unless the visitor has got IE or N6/Mozilla. In
an older browser, you can set up anchor elements and hyperlink inside the
page to scroll around. This is sometimes very useful, and makes
navigating a long page easier on your visitors.
Here's an example page that uses this: http://www.yankeeweb.com/practical/practical.html.
HTMLElement.addEventListener has been around a while now, but
it can't completely replace the specific methods that each vendor has had since
version 4. You use it like a method of an element, with three arguments: the
type of event, the handler function, and a boolean switch that turns on
capturing.
element.addEventListener('click',function,false);Note: you use the event type without the "on" prefix. And don't quote the
false, or you may make it evaluate to true.
If it is a transitory event you need to follow up with a
removeEventListener, passed the same arguments, to turn
it off.
The best use for it today is when you are truly adding an event--when an
element has an onclick or onmouseover event already, and you want to augment
the event without replacing it. When you mouseover a heading you may want to
pop up a description, and sometimes, but not always, insert a link into the
description. Or you could call an extra event if the visitor has selected
some combination of elements to view. In IE4 or Netscape Navigator you would
have to replace the original event handler, and add the new actions to the
old.
In N6/Mozilla and the DOM recommendation you add an event handler to the
element. Whatever else is set up for the element is still in place. Be sure to test
it--there is no guarantee that the order of events will be what you intend.
IE 5+ goes its own way again--you "attach" an event to the element. And when
you are through with it, you call detachEvent.
function addEvent(who,wot,evnt){
/*
who is an object reference to an element in the document.
wot is an event type- click, mouseover,blur . Note that IE
has to have the 'on' added to the event type.
evnt is a function reference.
If I used capturing I would send a fourth parameter
*/
if(document.addEventListener){
who.addEventListener(wot,evnt,false);
}
else if(window.attachEvent){
wot='on'+wot;
who.attachEvent(wot,evnt);
}
}This is a useful function, but limited. The DOM doesn't say anything about
keyboard events, and when you use addEventListener you can't examine
the element properties to see what is attached to what, but have to look for
specific eventListener registrations.
There's more--there is always more--but these examples should throw a little light on what you can do, and why, sometimes, you have to bend the standards a bit, if you want to write code that works.
Happy returns...
# # #
Kenneth Tibbetts is the creator of the Yankee Web Shop at http://www.yankeeweb.com/webshop.html and can be reached at: postmaster@yankeeweb.com.
| home / programming / javascript / events | [previous] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: April 10, 2002
Revised: April 10, 2002
URL: http://webreference.com/programming/javascript/events/2.html
