N
Noozer
Is it possible to detect where on a page the click occurred when the OnClick
event of the BODY tag is fired?
Thx
event of the BODY tag is fired?
Thx
Noozer said:Is it possible to detect where on a page the click occurred when the OnClick
event of the BODY tag is fired?
Danny said:I gather you want to detect the child clicked on?
From the event object passed as argument or the event. object, get the
.target for mozilla/opera or srcElement for IE/opera, yes Opera does both,
the event.target/event.srcElement returns the child clicked on once the
evnet is on the parent.
function checkwho(ev) {
obj=(window.external) ? event.srcElement : ev.target;
// IE is the only browser with window.external
alert(obj.nodeName)
}
document.body.onclick=checkwho;
RobG said:Yes. You can get the x,y coordinates of the cursor or a reference to the
element that was actually clicked on.
Which do you want?
I was looking for the actual element that was clicked on, although finding
the actual X and Y coordinates could be helpful for other items.
BTW, your code doesnt work in IE or Firefox... Firefox does nothing, IE
complains that "nodeName is nul or not an object".
The code from Danny works in IE, but again doesn't do anything in Firefox...
v1.06 if it makes a difference.
If you added it in the head, then yes, it'll fail since the body doesn't
exist when the script runs - it can't add an onclick to an element that
doesn't exist.
The links I posted give you very detailed explanations and working code,
use them in preference to any other code posted in this thread.
To get the posted code to work, add it in a script element just before the
closing body tag, or put it in the head and add the onclick with
window.onload. The following is purely an example, it is not intended to
be for a production web page:
<script type="text/JavaScript">
function showClickedElement( e )
{
e = e || window.event;
var obj = e.target || e.srcElement;
alert(obj.nodeName)
}
window.onload = function()
{
document.body.onclick = showClickedElement;
}
</script>
You should also remember that the body element does not necessarily extend
to the full extent of the window, either in width or height, so clicking
in the window may not fire the body's onclick event.
If the intention is to see if 'event' was passed to the function, the
logical thing to do is to check for that, not some property that you
think might indicate support for one event model or another.
also want to keep 'obj' local, there seems no point in it being a global
variable:
function checkwho( ev ) {
ev = ev || window.event;
var obj = ev.target || ev.srcElement;
Gérard Talbot said:RobG a écrit :
Also, the thing is that next week, maybe 3 browsers will
start to support window.external and those 3 browsers may
not support event.srcElement, therefore triggering later
in the code an unresolved js error.
Sorry but that is not the best way to create the code IMO.
It brings unneeded difficulties when debugging. ev is both
global and redefined: from a debugging perspective, this is
just creating more complexity. Mozilla js strict warning
feature will report this assignment as potential problem.
In my opinion (and subject to verifying that - ev - is a viable
reference following the assignment) that operation is optimal.
no issue with ev being global (it is not) and no reason not to assign a
value to it.
Mozilla's strict warnings seem to include some irrational (and frankly
silly) warnings, utterly inappropriate
ECMAScript, and I would recommend anyone using that browser for the task
to switch them off and concentrate on real errors. Strict warnings
become counter-productive as soon as they start to include the bogus.
Richard.
Gérard Talbot said:Richard Cornford a écrit :
The operation may be optimal; the coding manner is not
without some issue related to debugging, code legibility.
Then how about simply:
function checkwho( ev )
{
var TheEventObject = ev || window.event;
or
function checkwho( ev )
{
var objEvt = ev || window.event;
so that the variable name (value and assignment) does not
mask the passed argument.
Sometimes/often, they are useless, inappropriate; sometimes
they are not... the console won't provide long, detailed
explanations on the issue.
if(a=b)
{ ... };
will trigger a warning but if you're experienced, you can
ignore such warning.
If you're really experienced, you'll avoid assignment when
using an if simply because it makes the code less reliable,
reusable
and it does bring side effects, especially in iteration loops.
Some people do
if((a=b))
{ ... };
which is also ok but more mysterious...
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.