Hello and welcome to our community! Is this your first visit?
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 17 of 17
  1. #16
    Master Coder
    Join Date
    Feb 2003
    Umeň, Sweden
    Thanked 83 Times in 74 Posts

    Q: How do I hide my JavaScript source code?

    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.
    Last edited by liorean; Mar 4th, 2005 at 02:47 PM.

  2. #17
    Master Coder
    Join Date
    Feb 2003
    Umeň, Sweden
    Thanked 83 Times in 74 Posts

    Q: How do I use 'javascript:' links?

    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:
      <!DOCTYPE html PUBLIC "-//W3C//DTD HTML4.01//EN">
      <script type="text/javascript">
      function fnEscape(elm){
      function fnExecute(elm){
      <title>javascript: link creator</title>
          <textarea id="script"></textarea>
          <button onclick="fnEscape(document.getElementById('script'));">Escape</button>
          <button onclick="fnExecute(document.getElementById('script'));">Execute</button>
    • 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.
    liorean <[[email protected]]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts