when should I prefer stopPropagation to simply returning false?

[Jake Barnes]

On this page I'm given the impression that stopPropagation is a lot
like returning false:

http://www.brainjar.com/dhtml/events/default3.asp

"preventDefault () Can be used to cancel the event, if it is
cancelable. This prevents the browser from performing any default
action for the event, such as loading a URL when a hypertext link is
clicked. Note that the event will continue propagating along the normal
event flow.preventDef ault() Can be used to cancel the event, if it
is cancelable. This prevents the browser from performing any default
action for the event, such as loading a URL when a hypertext link is
clicked. Note that the event will continue propagating along the normal
event flow."
But often, if I want to stop a hyperlink from working normally, I can
simply return false from whatever action I've attached to that
hyperlink. Suppose I have this link:

<a id="link1" href="index.htm ">link text</a>

Suppose I attach the function "alertDange r" to this link:

function alertDanger() {
alert("Danger!" );
return false;
}
Because I return false, the default behavior doesn't occur. Would there
ever be a benefit to doing this instead:

function alertDanger() {
alert("Danger!" );
preventDefault( );
}

Perhaps preventDefault is only for those occassions when the code can
not or should not return?

[VK]

Jake Barnes wrote:

function alertDanger() {
alert("Danger!" );
return false;
}

Because I return false, the default behavior doesn't occur. Would there
ever be a benefit to doing this instead:

function alertDanger() {
alert("Danger!" );
preventDefault( );
}

In the latter case you have to provide a separate statement for IE,
because it doesn't have preventDefault( ) method, it uses instead
returnValue property you have to assign false for the same effect.

Moreover, you latter case doesn't work at all because preventDefault( )
/ returnValue are members of the event object, which is not default in
the function context.

Morover some older (but not too old to disregard) versions of non-IE
browsers still implement W3C-only event model, where the event object
is supplied as the first argument of the event handler: not as global
variable [event] like in IE schema.

So to bring it all together, we have to produce an ugly mess like:

function alertDanger(evt ) {
if ((evt)&&(evt.pr eventDefault)) {
evt.preventDefa ult();
}
else if ((event)&&(retu rnValue in event)) {
event.returnVal ue = false;
}
else {
// out of ideas...
}
}

Browser producers did not want to be beat down by developers for that
yet everyone wanted to stay on theirs. So as a compromise they came up
with an universal shortcut: returning false from the event handler will
mean e.preventDefaul t() / event.returnVal ue = false / whatever.

There is one legacy exception in this schema: to prevent default action
in window.onerror handler, you have to return true, not false. (That is
because window.onerror collector was made before any full-scaled event
schemas).

[VK]

I just noticed that your post is called "when should I prefer
stopPropagation to simply returning false?" which is a typo:
stopPropagation / cancelBubble have nothing to do with the subject of
your post (preventDefault vs. return false).

Just in case for other potential readers.

[VK]

VK wrote:

else if ((event)&&(retu rnValue in event)) {

else if ((event)&&('ret urnValue' in event)) {

That must be string with property name, not property itself, my typo,
sorry. Yet I hope no one will ever have to use this a la Browser Wars
agglomeration. Simply return false in the right places and be happy...