Section 26.2. Using JavaScript

26.2. Using JavaScript

Like many tools, JavaScript can be used for good or evil. The evil uses of JavaScript are all around: rapid-fire pop-ups that open faster than you can close them, sites that automatically set themselves as your home page, the list goes on and on. If that's what you're interested in doing, please stop reading now.

26.2.1. JavaScript Dos and Don'ts

As web professionals, we have a duty to make the user experience as positive as possible and make our sites both usable and accessible. We always need to consider how our choices as programmers impact our users. Not only should we not wield JavaScript maliciously, but we should take care to use it in such a way that a page or site can be used without it.

What? No JavaScript?!

There are many situations in which users may not have JavaScript turned on, even if their browser supports it. In many corporate environments, security concerns around web browsers have led to JavaScript being disabled. Also, several accessibility experts have advocated for users of assistive devices (such as screen readers) to disable JavaScript because of the massive amount of obtrusive JavaScript in use that makes it difficult for them to easily navigate and use the Web.

As with CSS, JavaScript should "degrade gracefully," in other words, your scripts should be written in such a way that they know if they will be able to run or not and quietly fail if methods they make use of are not supported. It is also important, for many reasons, including accessibility, that your scripts be unobtrusive. This is easily tested by turning off JavaScript support entirely in your browser to make sure the page can still be used.

This is a topic that will be touched on several times throughout this chapter and the next, but we'll begin by discussing how to use JavaScript in your pages.

26.2.2. Implementation Methods

JavaScript can be implemented on a single page or on an entire site. As with CSS, it can be embedded in a document, or externalized from that document. Both methods are accomplished using the script element.

We'll start with an embedded example:

     <script type="text/javascript">       // <![CDATA[       ... JavaScript code goes here ...       // ]]>     </script> 

As you can see, the script element establishes the block as being a script and the MIME-type is set (using the type attribute) to be text/javascript (text/ecmascript would also be acceptable).

The // <![CDATA[ and // ]]> may be unfamiliar to you, but you can find out more about CDATA in Chapter 7. As for the //, which you see in front of each part of the CDATA designation, those are one of the ways of designating comments in JavaScript, and we are telling the script above to ignore the remainder of each of those lines.

Externalizing your JavaScript is the preferred method of implementation, as it affords you the opportunity to include the same functions or functionality on multiple pages (and you can avoid declaring the content as CDATA). Here is how you would externalize a script:

     <script type="text/javascript" src="/books/4/439/1/html/2/my_script.js"></script> 

In this example, we have moved our JavaScript into a separate file and simply included it in our document by calling its filename as the source (src) of the script element. You can include as many scripts as you like in this way and even combine this approach with embedded script calls, as in this example from Google Analytics (www.google.com/analytics/):

     <script src="/books/4/439/1/html/2/http://www.google-analytics.com/urchin.js"       type="text/javascript"></script>     <script type="text/javascript">       // <![CDATA[       _uacct = "UA-XXXXXX-X";       urchinTracker( );       // ]]>     </script> 

The external script resides on the Google server and is the same for everyone using Google Analytics. The embedded script establishes the user account (the _uacct variable) and then triggers the urchinTracker function to run.

It is recommended that you keep script elements in a common area in the head of your (X)HTML pages. This is more out of convention and maintainability than anything else. After all, who wants to have to hunt for a script within a several hundred- or thousand-line document? That said, script is perfectly valid within the body as well.