This is a concept in Event Handling of JavaScripts in HTML. Before explaining this, I need to make sure that you are aware of adding Event Handlers, the earlier days way, way before the second Browser Wars and jQuery Invention.

The oldest browsers support only one way of registering event handlers, the way invented by Netscape. At that time, there were no compatibility problems, because, at this time, Internet Explorer 3 for Mac, which doesn’t support events at all.

Event Handler Registration
You can register an event handler in three ways.

1. Inline Event Registration.
2. Type 1 Event Registration.
3. Type 2 Event Registration.

Inline Event Registration
In the inline event registration model, event handlers are added as attributes to the HTML elements this way:

<A HREF="newpage.html" onClick="alert('I\'ve been clicked!')">

When this link is clicked, the event handler is executed, bringing up an alert dialog and navigates to newpage.html.
You can also invoke a JavaScript function this way:

<A HREF="newpage.html" onClick="doThis()">

It is just because of a tradition, we have used the mix of upper and lower case in the event names (onClick, onMouseOver) here. HTML is not case sensitive, which means, ONCLICK, onclick, OnClick, and onClick, all mean the same. But, if you are using XHTML, you must write all the attributes in lower case like onclick and onmouseover.

Don’t Use Inline Event Registration Model
Even though the Inline Event Registration Model is very reliable, it is not recommended. The reason is, it requires you to combine the JavaScript and XHTML, which makes an entry for a Business Layer inside a Presentation Layer. Understanding this old model is necessary for a full overview of JavaScript event handling, but you should use one of the modern models which I describe later on.

Type 1 & 2 Event Registration Models
Since we are not concerned more on Event Registration Models, I would just brief you how these two differ or work.

Type 1 is by writing a script tag for the sake of an element. It can be written as this way, below:

<script type="text/javascript" for="ElementID">

Type 2 is by getting the ID of the element in the script and assigning an Event Handler. It can be done by:

<script type="text/javascript">    element.onclick = function(){        alert(this.innerHTML);    }</script>

Enough of Event Handling Stuff! Now to the main thing?
We all know that, when a user clicks on a link, the browser navigates to the page specified in its href attribute. This is the default action caused by a click event on a link. But what happens when you’ve also defined an onclick event handler? It should be executed, but when?

<A HREF="newpage.html" onClick="doThis()">

In the case of a click on a link, the event handler must be executed first. After all, when the default action takes place —new page is loaded— the old page, including the event handler, is removed from browser memory. Therefore if the onclick event handler is to be executed at all, it must be done before the default action.

This has become an important principle of event handling. If an event causes both a default action and execution of a event handling script:

1. The Event Handler script is executed first.
2. The Default Action takes place afterwards.

So in our example the function doThis() is executed first, only then does the browser follow the link.

Preventing the Default Action
Since the Event Handler executes even before the default action of navigating to a link, in our example it should be possible to prevent the browser from loading a new page.

Therefore the event handler can return a boolean (true or false), and false means: “don’t take the default action”. So if we change our example to:

<A HREF="newpage.html" onClick="doThis(); return false;">

The link is not executed or never followed by the browser. The function is executed and after that the event handler returns false, telling the browser not to take the default action.

This way, even we can make custom function, which decides based on user, whether to allow the default action or not. This can be achieved by:

<A HREF="newpage.html" onClick="return doThis();">function doThis(){    return confirm('Do you really want to go to this link?')}

This is a very simple way of interacting with the user. The user is asked a question; if he clicks ‘OK’, the function returns true, if he clicks ‘Cancel’, the function returns false.

This returned value is caught by the event handler, which in turn returns it to the event itself. If false is returned the default action is canceled – link is not followed.

However, you cannot prevent all default actions. An unload, for example, cannot be prevented. Suppose the user closes the browser window – causing an unload event in the page in the window. If you could prevent the unloading, would that mean the window stays open regardless of the wishes of the user? No chance!

IE to the Rescue! You can try to stop the unloading with Microsoft’s proprietary beforeunload event. But, even then the user is asked to confirm this prevention of the default action, creating a very confusing situation! Better don’t use it.

Returning false to prevent the default action works in all browsers, it’s a basic part of event handling. Modern event handling models have added some new ways of preventing the default:

W3C has added the method preventDefault() to the event. If you call it the default action is prevented.
Microsoft has added the property returnValue to the event. If you set it to false the default action is prevented.

But you don’t need to use them, a simple return false also does the job.

The window.status Exception!
There’s one exception to the return false rule. When you change the status text of the window after the user mouseovered a link, you also want to prevent the default action – show HREF in status bar. To do this you must return true:

<A HREF="newpage.html" onMouseOver="window.status = 'This link goes somewhere'; return true">

What is The Use?
Okay! I guess I have explained enough about Event Handling, now coming to our thing, why do we need this? I hope many of us would have seen web pages with tabs in them. These tabs are just list elements <li> tags with a linked text and they are linked to the ID of the content <div> with their href attribute pointing to the # with ID.

jQuery does it this way. The $("#elem") refers to the element with an id attribute equal to elem. Now we have the href attribute having the ID of the element this way:

<li><a href="#tab1">Tab 1</a></li><li><a href="#tab2">Tab 2</a></li><li><a href="#tab3">Tab 3</a></li>

The ID from the link can be extracted this way:

var elem = $(this).attr("href"); // this refers to the calling A tag

Now we can issue a jQuery show() or fadeIn() command to display the element, which is specified in the href attribute of the link. And, giving a return false; to the onclick event of the links, won’t allow the browser to follow the link, thereby, you get the tab opened as well as the page stays where it is.