Main Points

Javascript was originally developed by Netscape waaaaaay back in the 1990s. The first version was very limited and the second was so powerful it lead to major security breaches. It has been scaled back since and security on PCs (and browsers) beefed up; the result is a useful while relatively safe language. However, to this day there are still organizations and retailers so traumatized by Javascript that the funtionality is turned off. As such, it needs to be evaluated carefully not just because of it's power and security issues, but because of the hit and miss support among visitors over which you have absolutely No control.

Javascript: Pros and Cons

We have some Javascript demos that we used when we first started to develop. It wasn't long before we made the decision to convert to unobtrusive Javascript. For anyone not familiar with it, Javascript is a problematic technology. It has some key advantages. Javascript is client side. First, this saves the server time and trouble. Rather than wasting server time computing things, you can download the code to the visitor's browser and let the visitor's computer do the computations. Javascript also allows you to do things that you simply couldn't do with server side code. Anything that moves on a webpage, besides Flash, basically has to be Javascript driven. So everything interactive is pretty much Javascript.

On the downside, some browsers still don't have full Javascript support; especially text browsers. Another key difficulty is Internet Explorer. Microsoft began having difficulty keeping up with internet threats and suffered one high profile security failure after another. Rather than take these threats seriously, Microsoft's new philosophy is that Javascript is dangerous and should be disabled by default. Now, most people do in fact enable Javascript in their browsers, to which Microsoft can say in court, "We told you not to do it!" So Internet Explorer is not any more secure, but Microsoft has plausible deniability. The REAL problem is that there is a sizable fraction of your visitors who don't know how to change the defaults of IE, and so developers can't assume Javascript supported by all visitors.

[chroniclemaster1, 2007/07/08]

  1. JavaScriptTest.html - This page predates Earth Chronicle; it's from way back when we first began learning Javascript. It was a large scale exercise in Javascript behaviors. Fortunately, we simply abandoned this page when we moved to the new website. It's retained for historical interest. The Javascript is done "badly" using inline calls and scripts embedded in the <head> tags. Having done it this way, I can tell you that it was definitely easier to do, however, it was very obnoxious for many visitors who did not have "perfect" Javascript support.

    [chroniclemaster1, 2007/07/08]

Unobtrusive Javascript: A Solution?

The new philosophy in Javascript that attempts to deal with these issues is called Unobtrusive Javascript. It uses Javascript to enhance the function of your site, while visitors with different levels of Javascript support never find anything broken. A unobtrusive website may have many more features available to visitor with full Javascript support than it does to a visitor with Javascript turned off. However, at all times and for all visitors, the site appears to operate correctly. Visitor's have access to the functions they can use safely, if any, and never know about functions unavailable to them. This is called "graceful degradation" by some and "progressive enchancement" by others, though the techniques each group uses is similar. The key practice of Unobtrusive Javascript is to remove all the Javascript code to a separate .js file. This is not only best practice for supporting - while not requiring - Javascript, it also consolidates all Javascript for the website in one easy to maintain place.

On Earth Chronicle Beta, everything is indeed located in our .js file. Our key use for Javascript is the navmenus of our navigation bar. If someone visits the site without proper Javascript support, these menus are simply unavailable. This works fine, because such visitors never know that there should be menus. And yet visitors without Javascript still have a fully functional navbar. They simply have to make due with the navbar buttons. We planned the navbar with this in mind, so you will notice that the navbar buttons link to the most important pages for the website. The menus give you additional related pages, but the site still functions without them; this is one reason for the accessible page links at the bottom of the webpage. You can navigate easily without the navmenus, just not as easily as you can with full Javascript support.

Finally, we also use Javascript to build the clock. This is the most problematic use, as the text field for the clock is written into the XHTML of the webpage. If a visitor without Javascript visits our site, the clock appears as an empty text field that does nothing. This isn't technically broken, but it is problematic. It is the only time a visitor will know that something isn't quite right if they don't have Javascript support. We hope to rebuild the clock as a label div, especially if the background color is the same as the page, this may achieve the same level of accessibility that our navbar solution has reached. However, that is a lower priority right now. I'm much more interested in reprogramming the navmenu behavior so that the code isn't so bulky. Our Javascript file is over 10K, and more than half is highly redundant calls to control the navbuttons. However, our attempts to build subroutines have so far run afoul of the Document Object Model (DOM). We've had to reprogram script for problems such as a menu that drops down but then vanishes when you move your mouse over a link. When we work out a syntax that works, we'll be incorporating that into our Javascript file

[chroniclemaster1, 2007/07/08]

So much for problems. We've now rewritten the clock as a styled div instead of a text field, so we don't have the naked text box problem anymore. Plus it looks better. We finagled around inactive Javascript a bit creatively on the clock too. If a visitor has Javascript support, they get the fully functional clock. But if they don't, they get an Earth Chronicle motto. So viewing the site without Javascript gives you access to one of our Easter eggs, rather than just giving you a broken clock. We used the div's innerHtml property to transform it's content. In fact, you never know that anything is wrong. It looks like the div was styled especially for the motto.

[chroniclemaster1, 2007/07/17]

Original Unobtrusive Javascript Tests

These were our first attempts to build unobtrusive Javascript. You can see we started pretty simple, but used it to lay a foundation which we could build on each step of the way. Most of it is related to building our CSS / Javascript menu based navbar.

  1. Trigger a Javascript Event from a File - This was our first test to see if we could get unobtrusive Javascript to work.

    [chroniclemaster1, 2007/05/12]

  2. Change the Display on a Div - Next we moved in the direction of running our navbar menus unobtrusively. We demonstrated control over the display of a div.

    [chroniclemaster1, 2007/05/12]

  3. Show and Hide a Div - Next we extended the principle to being able to hide the div once again, as well as showing it.

    [chroniclemaster1, 2007/05/12]

  4. Javascript File Driven Menus - In this phase we demonstrated that we could build code to handle more than one menu.

    [chroniclemaster1, 2007/05/12]

  5. XHTML Id Detection Subroutine - Rather than build on the previous work, we needed to find a way to generalize the functions, basically we need to rebuild them to save on file size. Here's our first attempt that could identify the ID of an element on the fly. There's one minor problem.

    [chroniclemaster1, 2007/06/14]

  6. Subroutine Driven Navbar - Here's a navbar the way you'd expect to work it. Everything seems fine.

    [chroniclemaster1, 2007/06/14]

  7. Oops! Adding Links - And then disaster struck. When we built the working version, there's no way to mouse over the links. IE throws an error, and Firefox triggers the subroutine that hides the div.

    [chroniclemaster1, 2007/06/14]

  8. Passing Parameters - But fear not, every obstacle leads you to another path. We worked out the syntax for working with unobtrusive functions and passing parameters into them. And it works much better.

    [chroniclemaster1, 2007/07/16]

  9. Contact Form - Image Rollovers - We had trouble with the image in the contact form; the first attempt to build an unobtrusive rollover script killed the navbar menus. It took a little more work to get everything playing nicely together.

    [chroniclemaster1, 2007/07/16]

  10. Navbar - Condensing Event Handlers - We have several dozen event handlers to cover the functioning of the navbar. There's got to be a better way.

    [chroniclemaster1, 2007/08/21]