From DHTML to DOM Scripting

By Christian Heilmann

Notice that this simply defines what layers are available, not how they interact. For example, something needs to convert content to structure (such as XSLT), and something needs to connect the upper four layers with the business logic. If you manage to keep all these layers separate, yet talking to each other, you will have succeeded in developing an accessible and easy-to-maintain web site. In the real development and business world, this is hardly the case. However, the more you make this your goal, the fewer annoying changes you'll have to face at a later stage. Cascading Style Sheets are powerful because they allow you to define the look and feel of numerous web documents in a single file that will be cached by the user agent. JavaScript can act in the same fashion by using the src attribute of the script tag and a separate .js file.

In earlier chapters of this book, we embedded JavaScript directly in HTML documents (and you may remember that this is tough to do for XHTML documents). This we will not do from this point on; instead, we'll create separate JavaScript files and link to them in the head of the document:

<html dir="ltr" lang="en">
    <meta http-equiv="Content-Type" content="text/html;
    <style type="text/css">@import 'styles.css';</style>
    <script type="text/javascript" src="scripts.js"></script>
    <script type="text/javascript" src="morescripts.js"></script>
We should also try not to use any script blocks inside the document any longer, mainly because that would mix the structure and the behavior layers and can cause a user agent to stop showing the page should a JavaScript error occur. It is also a maintenance nightmare--adding all JavaScript to separate .js files means we can maintain the scripts for a whole site in one place rather than searching through all the documents.

Note While Firefox, Safari, and Opera display .js files as text, Microsoft Internet Explorer tries to execute them. This means that you cannot double-click or point your browser to a JavaScript file to debug it in MSIE--something that is pretty annoying when debugging code. This instant code execution is a security problem, which is why Windows XP2 does flag up any JavaScript content in local files as a security issue as shown in Figure 3-2. Do not get fooled by this--it is your code, and, unless you are a malicious coder, it is not a security issue.

Figure 3-2. Microsoft Internet Explorer on Windows XP2 shows a warning message when you try to execute JavaScript locally.

This separation of JavaScript into its own file makes it simpler to develop a web site that still works when the script is not available; and if a change in the site's behavior is needed, it is easy to change only the script files. This is one of the bad habits of DHTML squashed: HTML can exist without JavaScript, and you do not need to scan a lot of documents to find out where a bug occurred. The next bad habit of DHTML was browser dependence, which we'll now replace with object detection.

Object Detection vs. Browser Dependence

One way to determine which browser is in use is by testing the navigator object, which reveals the name and the version of the browser in its appName and appVersion attributes. For example, the following script gets the browser name and version and writes it out to the document:
<script type=" text/javascript">
  document.write("You are running " + navigator.appName);
  document.write(" and its version is " + navigator.appVersion);
On my computer, inside Macromedia HomeSite's preview mode, this script reports the following (as HomeSite uses the MSIE engine for previewing HTML). You are running Microsoft Internet Explorer and its version is 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) If I run the same script in Firefox 1.07 on the same computer, I get You are running Netscape and its version is 5.0 (Windows; en-GB)

A lot of older scripts use this information to determine whether a browser is capable of supporting their functionality.

<script type="text/javascript">
 if(browserName.indexOf('Internet Explorer')!=-1
  && browserVersion.indexOf('6')!=-1)
    document.write('<p>This is MSIE 6!</p>');
    document.write('<p>This isn\'t MSIE 6!</p>');
This appears rather clever at first glance, but as the output of Firefox shows, it is not a bullet-proof method of finding out which browser is in use. Some browsers like Opera won't even reveal themselves to scripts, but appear as Microsoft Internet Explorer instead.

Tip Opera is by default set up to tell scripts that it is MSIE. The reason for this is that Opera Software didn't want its browser to be blocked by web sites that were developed for MSIE only. Sadly enough, a lot of devel-opment went that route and Opera Software just didn't want to lose customers or answer a lot of angry e-mails why its "bad" browser doesn't work with web site XYZ. However, it also means that Opera doesn't show up in browser statistics of web sites and remains unimportant for those who just see the visitor numbers and what browser they use (a lot of statistics software uses the navigator object). If you are an Opera user and you want to turn off this preset, press F12 and choose "Identify as Opera" instead of "Identify as Internet Explorer."

Reading out the browser name and version--commonly known as browser sniffing--is not advisable, not only because of the inconsistencies we just encountered, but also because it makes your script dependent on a certain browser rather than supporting any user agent that is actually capable of supporting the script.

The solution to this problem is called object detection, and it basically means that we determine whether a user agent supports a certain object and make this our key differentiator. In really old scripts, like the first image rollovers, you might have seen something like this:

<script type="text/ javascript">
  // preloading images
    // Images are supported
    var home=new Image();
    var aboutus=new Image();

Page 2 of 4

Previous Page
1 2 3 4
Next Page

Make a Comment

Loading Comments...

  • Web Development Newsletter Signup

    Invalid email
    You have successfuly registered to our newsletter.
Thanks for your registration, follow us on our social networks to keep up-to-date