What you should know about "javascript:"

Several years ago I posted on the ASP.NET forums a conversation piece. I received much feedback with the presentation of a topic that, even then, was an artifact feature of HTML interpretations. The anchor tag over the decades has been abused beyond what should be normal use. This humble tag had been the hook for many actions that a user may take upon a page.
But what exactly should this tag be used for? User interaction? Links? Both? At first glance the answer would be yes. However, this tag was designed to present two distinct processes in HMTL.

1. Present the user with a way to connect with other resources on the internet through linking.
2. Present the user with a destination for those links to target.

Today with "Single Page Applications" and in years gone by, the process of "deep linking" utilizes the achor tag as it should. In the most raw form two anchor tags, one with an href value and the other with an id value, are placed on the page and when the link is clicked the anchor with the id is placed at the top left origin of the page. Nothing new, just the fundamental functionality of this fantastic tag.

The abuse of this tag originates with the birth of JavaScript. Browsers introduced a scripting language that allowed developers to provide the flare and excitement that static mundane webpages could not truly provide. Developers began experimenting and abusing where they could execute JavaScript. Developers would discover that you can place JavaScript inside the href of an anchor tag, while this is fine as the browser is suggested to expect this, but it is not a proper use of the tag. Do not do this. Let me explain.

1. JavaScript is not a protocol it is a script language. You use it on element event handler attributes and inside the <script type="text/javascript"></script> tag. And it runs only on the client. JavaScript meant for the Client will only ever be interpreted by the Client Browser and not by the server¹
2. Form fields fire events throughout their lifetime. It is always expected as JavaScript. To force the events to fire through vbScript or jScript is irresponsible and limits your application to a specific browser. When you declare a JavaScript function or string of code in an element's event handler attribute you do not specify the language. You also bind your presentation code to your application code, violating the 'separation of concern' rules.
3. Using JavaScript in an href breaks web crawlers and your page's SEO rankings will drop drastically. Like the Titanic(Your SEO) in the Atlantic Ocean(The Internet). When a crawler encounters href="javascript:-----" it has no idea what to do and does not execute the JavaScript². If you wrote an awesome method to handle your links and are doing this, those pages are not accessible to the search engine(s) crawler and you don't get a page rank for those pages. Also some SEO ratings ding your scores for bad HREFs as well.
4. Doing the above also hurts your accessibility. People whose specialized browsers do not run JavaScript won't be able to traverse your pages and so they will move on and you won't have anyone visiting your site anymore². This comes down to your audience and what your page expectations are. 

The following code illustrates this coding practice.

The following code illustrates how one should approach functionally around the anchor tag. While the jQuery code presented may be old fashion, it is meant to illustrate the event binding that should occur in your JavaScript code instead of using the practices of a time long since forgotten.

¹ There are some pre-processing practices that some developers use that will execute the JavaScript on the server for various reason. This is not a standard practice, nor is is one that I promote myself. This practice is not part of this conversation.

² This statement is made with the understanding that web crawlers and accessibility tools have traditionally not supported much in the way of JavaScript execution. These products evolve just as any software does and I would be surprised that they are not supporting more and more JavaScript execution as time progresses.

References:

• Matt Kruse - JavaScript Best Practices

ASP.NET Post:

• What you should know about "javascript:"