Event Handler Question

[eggie5]

I have this even handler (using prototype.js):

showCommentsLinks.observe('click', function(event)
{ alert('hi') });


It's attaching to a link element:

<a id="showCommentsLink" href="comments/">Show Comments</a>

When ever my event handler is called, which can be implied as
javascript is enabled and working, I want to prevent the the browser
from following the href url.

If i wasn't using unobtrusive javascript, I would go like this:

<a id="showCommentsLink" href="comments/" onclick="alert('hi');return
false;">Show Comments</a>'

and that would prevent the browser from going to /comments after the
JS executes. How can I recreate this functionality with the
unobtrusive event handler above?

 

[RobG]

I have this even handler (using prototype.js):

showCommentsLinks.observe('click', function(event)
{ alert('hi') });

It's attaching to a link element:

<a id="showCommentsLink" href="comments/">Show Comments</a>

Just because you are using Prototype does not mean you *must* use
Event.observe. In fact, you are better to only use it where its use
is specifically indicated (which is not very often).

Just have the function return false:

<script type="text/javascript">

function hi(){
alert('hi');
return false;
}

window.onload = function(){
document.getElementById('a00').onclick = hi;
}

</script>

<a href="http://..." id="a00">some link</a>


Or if your function doesn't return false, use:

window.onload = function(){
document.getElementById('a00').onclick = function(){
hi();
return false;
}
}

When ever my event handler is called, which can be implied as
javascript is enabled and working, I want to prevent the the browser
from following the href url.

If i wasn't using unobtrusive javascript, I would go like this:

<a id="showCommentsLink" href="comments/" onclick="alert('hi');return
false;">Show Comments</a>'

Most of what is included under the misnomer of 'unobtrusive
javascript' is ill-conceived - unobtrusive to whom? Can you provide a
definition?

Consider the example above. If a user clicks the link before the page
finishes loading, they will navigate to the link because your onload
handler hasn't added the A element's onclick handler yet. But if
you'd added it in-line, it would be there doing its job - which is
less obtrusive?

Maybe that's the effect you want, but the different behaviours may
surprise users.

and that would prevent the browser from going to /comments after the
JS executes.

Only if the page has finished loading and the handler has done its
job.

 

[eggie5]

I have this even handler (using prototype.js):

showCommentsLinks.observe('click', function(event)
{ alert('hi') });

It's attaching to a link element:

<a id="showCommentsLink" href="comments/">Show Comments</a>

Just because you are using Prototype does not mean you *must* use
Event.observe. In fact, you are better to only use it where its use
is specifically indicated (which is not very often).

Just have the function return false:

<script type="text/javascript">

function hi(){
alert('hi');
return false;
}

window.onload = function(){
document.getElementById('a00').onclick = hi;
}

</script>

<a href="http://..." id="a00">some link</a>

Or if your function doesn't return false, use:

window.onload = function(){
document.getElementById('a00').onclick = function(){
hi();
return false;
}
}

When ever my event handler is called, which can be implied as
javascript is enabled and working, I want to prevent the the browser
from following the href url.

If i wasn't using unobtrusive javascript, I would go like this:

<a id="showCommentsLink" href="comments/" onclick="alert('hi');return
false;">Show Comments</a>'

Most of what is included under the misnomer of 'unobtrusive
javascript' is ill-conceived - unobtrusive to whom? Can you provide a
definition?

Consider the example above. If a user clicks the link before the page
finishes loading, they will navigate to the link because your onload
handler hasn't added the A element's onclick handler yet. But if
you'd added it in-line, it would be there doing its job - which is
less obtrusive?

Maybe that's the effect you want, but the different behaviours may
surprise users.

and that would prevent the browser from going to /comments after the
JS executes.

Only if the page has finished loading and the handler has done its
job.

If I set up the event handler by means of:

document.getElementById('a00').onclick = function(){

If any other code attaches tot he onclick the previous code will not
execute.

 

[RobG]

I have this even handler (using prototype.js):
showCommentsLinks.observe('click', function(event)
{ alert('hi') });
It's attaching to a link element:
<a id="showCommentsLink" href="comments/">Show Comments</a>

Just because you are using Prototype does not mean you *must* use
Event.observe. In fact, you are better to only use it where its use
is specifically indicated (which is not very often).

Just have the function return false:

<script type="text/javascript">

function hi(){
alert('hi');
return false;
}

window.onload = function(){
document.getElementById('a00').onclick = hi;
}

<a href="http://..." id="a00">some link</a>

Or if your function doesn't return false, use:

window.onload = function(){
document.getElementById('a00').onclick = function(){
hi();
return false;
}
}

Most of what is included under the misnomer of 'unobtrusive
javascript' is ill-conceived - unobtrusive to whom? Can you provide a
definition?

Consider the example above. If a user clicks the link before the page
finishes loading, they will navigate to the link because your onload
handler hasn't added the A element's onclick handler yet. But if
you'd added it in-line, it would be there doing its job - which is
less obtrusive?

Maybe that's the effect you want, but the different behaviours may
surprise users.

Only if the page has finished loading and the handler has done its
job.

If I set up the event handler by means of:

document.getElementById('a00').onclick = function(){

If any other code attaches tot he onclick the previous code will not
execute.

That is an old excuse that doesn't stand up to scrutiny.

In what environment can you safely add as many handlers as you like to
an element, in no particular order, without regard for other handlers
that might already be there? In this specific case you want to stop
propagation - how do you know it's safe to do that if you don't know
what other handlers are there and whether they want the event to
propagate? How do you know the order in which they will be called?

You can only safely add multiple handlers if you know exactly what
each one will do and that order is unimportant. Otherwise, you are
much safer to add one handler that calls all the others as functions
in a known order and context.

In a very few cases you might want to add multiple handlers using
attachEvent and addEventListener, but imagine that is the exception
rather than the rule.

The above does not address the other issues of trying to make
addEventListener and attachEvent behave consistently in different
browsers.

 

[eggie5]

I have this even handler (using prototype.js):
showCommentsLinks.observe('click', function(event)
{ alert('hi') });
It's attaching to a link element:
<a id="showCommentsLink" href="comments/">Show Comments</a>
Just because you are using Prototype does not mean you *must* use
Event.observe. In fact, you are better to only use it where its use
is specifically indicated (which is not very often).
Just have the function return false:
<script type="text/javascript">
function hi(){
alert('hi');
return false;
}
window.onload = function(){
document.getElementById('a00').onclick = hi;
}
</script>
<a href="http://..." id="a00">some link</a>
Or if your function doesn't return false, use:
window.onload = function(){
document.getElementById('a00').onclick = function(){
hi();
return false;
}
}
When ever my event handler is called, which can be implied as
javascript is enabled and working, I want to prevent the the browser
from following the href url.
If i wasn't using unobtrusive javascript, I would go like this:
<a id="showCommentsLink" href="comments/" onclick="alert('hi');return
false;">Show Comments</a>'
Most of what is included under the misnomer of 'unobtrusive
javascript' is ill-conceived - unobtrusive to whom? Can you provide a
definition?
Consider the example above. If a user clicks the link before the page
finishes loading, they will navigate to the link because your onload
handler hasn't added the A element's onclick handler yet. But if
you'd added it in-line, it would be there doing its job - which is
less obtrusive?
Maybe that's the effect you want, but the different behaviours may
surprise users.
and that would prevent the browser from going to /comments after the
JS executes.
Only if the page has finished loading and the handler has done its
job.

If I set up the event handler by means of:

document.getElementById('a00').onclick = function(){

If any other code attaches tot he onclick the previous code will not
execute.

That is an old excuse that doesn't stand up to scrutiny.

In what environment can you safely add as many handlers as you like to
an element, in no particular order, without regard for other handlers
that might already be there? In this specific case you want to stop
propagation - how do you know it's safe to do that if you don't know
what other handlers are there and whether they want the event to
propagate? How do you know the order in which they will be called?

You can only safely add multiple handlers if you know exactly what
each one will do and that order is unimportant. Otherwise, you are
much safer to add one handler that calls all the others as functions
in a known order and context.

In a very few cases you might want to add multiple handlers using
attachEvent and addEventListener, but imagine that is the exception
rather than the rule.

The above does not address the other issues of trying to make
addEventListener and attachEvent behave consistently in different
browsers.

Here's an example that's handy:

I was using messing around with a validation framework called xf.js
and it was attaching the onsubmit of my form in the way you describe.
However, since it doing it like that it was overwriting any event
handlers I attached to the onsubmit.