Thread: JavaScript - Frequently Asked Questions

A: JavaScript, the way you most likely are using it, is a client side technology. That means that if you at all want to use JavaScript on your web site, it must be sent to the client in such a way that it can be read by the client machine and executed there. What happens at the client is not controllable by you - if the machine is able to read it, so is your user. Thus, any try at hiding the source code is futile. Anything you try to do to make it harder to read by the user is still not enough, because when the machine can read it out for execution, so can a user. So, forget all about trying to protect your source code. Place a copyright statement on it instead, that's the best copy protection that you will be able to find.

A: Consensus on this area among professional web designers is that they shouldn't be used at all. There are strong arguments arguments towards this, from usability, accessibility, optimisation and standards comformance perspectives. Before I tell you how to use them, please read through this list first...

• Usability:
  Something not often mentioned but one of the most important
  factors in my view, is that the 'javascript:' pseudo-URI destroys
  several layers of usability features. E.g:
  - The link does in most cases only work when simply clicked, it
  generally no longer works:
  * When bookmarked
  * When users chose 'open in new window' or 'open in new tab'
  * When users to copy the link to clipboard for offline referencing
  - Browsers that handle internal and external links different no longer
  knows what kind of link it is
• Accessibility:
  Of course, it's a question whether some users are able to use the
  resource at all...
  - The link does not work in JavaScript disabled environments such as
  many corporate environments
  - The link does no longer work in browsers that fail at supporting
  JavaScript, such as many mobile phone and PDA browsers
• Optimisation:
  There are different kinds of optimisations, but some common ones are
  size and search engine optimisations.
  - Links using 'javascript:' pseudo-URIs generally don't get spidered
  by search engines.
  - SCRIPT bodies in the HEAD or early in the BODY are generally
  severely downgrading the relevancy of your page for any search terms
  appropriate for the content, in the views of the search engines.
  - If embedded in the page, the script adds to the size of the page
  that the user has to download. That means that you have to pay for
  larger data transfer ratios, and the user has to wait longer for the
  page to download
  - Scripts that are scattered through the site take more time to
  upgrade and more work to maintain than if you instead moved all
  scripting to separate files, leaving the HTML scriptless.
• Standards conformance:
  There are a lot of web standards that you can have a look at. There's
  also a level of conformance that could be called conforming to the
  spirit of standards, as opposed to just the word of them.
  - There is no 'javascript' URL scheme registred, so it's not a valid
  resource identifier
  - There are no specific security or semantics formally defined for the
  'javascript' pseudo-URIs
  - In the spirit of the semantic web, behavior as provided by scripting
  should not be part of the document structure and/or content unless the
  behavior can be considered to be the actual content provided

In other words, the best way to use them is to not use them. Anyway, for those of you that aren't convinced, here's how they work:

• The javascript: part tells the browser what protocol it should use in getting to the resource. In this case, the return value of the code that follows will be the resource the browser tries to display.
• Next comes the actual script contents. This content must conform to the same rules that govern all URIs, as well as all rules that govern SGML attributes. If you didn't understand what I just said in the last sentence, here's a little explanation for you: Content of a URI places a few special meanings on some characters, and these characters must thus be 'escaped' - replaced with a representation that does not carry any meaning. In the same way, HTML also places a meaning on some characters. This means that you need to escape these characters too. Some of these characters may be used in JavaScript, so it's important that you escape them. Now, how do you escape characters, then? Well, there's an easy way to do it if you don't want to have to bother with it yourself. Make a page as listed below and run it in your browser. Enter the script you want to escape, and press the "Escape" button:
  Code:

  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML4.01//EN">
  <script type="text/javascript">
  function fnEscape(elm){
      elm.value='javascript:'+encodeURIComponent(elm.value);
  }
  function fnExecute(elm){
      document.location=elm.value;
  }
  </script>
  <title>javascript: link creator</title>
  <fieldset>
      <textarea id="script"></textarea>
      <button onclick="fnEscape(document.getElementById('script'));">Escape</button>
      <button onclick="fnExecute(document.getElementById('script'));">Execute</button>
  </fieldset>

• That's not all, however. Links using 'javascript:' pseudo-URIs have a behavior such that if the code returns a value, that value will replace the current page, just like a normal link would. If the code on the other hand doesn't return a value, or returns the value undefined, it will not replace the current page. That means that you often want to write code like this: javascript:void(your code);. If you also don't want to overwrite any global variables you might use in the code, you can write the slightly longer javascript:(function(){your code})();.

However, 'javascript:' pseudo-URIs are mostly done entirely wrong. In almost all cases, you should have a real link in the href attribute and instead use JavaScript to override that behavior in the onclick event handler. So, here's the last thing I'll tell you:

The only case where you really want to use a 'javascript:' pseudo-URI is when you are creating bookmarklets - which could be described as small snippets of javascripts that work on any page, not just the one you place the link. Examples of this use can be for example DOM tree viewers. In all other cases, it's neither the best tool for the job nor the right thing to do, so don't.