From DHTML to DOM Scripting

From DHTML to DOM Scripting

In this chapter, you’ll learn what DHTML was, why it is regarded as a bad way to go nowadays, and what modern techniques and ideas should be used instead. You’ll learn what functions are, and how to use them. You’ll also hear about variable and function scope and some state-of-the-art best practices that’ll teach your scripts how to play extremely well with others. If you are interested in JavaScript and you have searched the Web for scripts, you surely have come upon the term DHTML. DHTML was one of the big buzz words of the IT and web development industry in the late 1990s and beginning of the millennium. You may have seen a lot of tutorials about achieving a certain visual effect on now outdated browsers rather than explaining why this effect makes sense and what the script does. And that is exactly what DHTML was about.

Note DHTML, or Dynamic HTML, was never a real technology or World Wide Web Consortium (W3C) stan-dard, merely a term invented by marketing and advertising agencies. DHTML is JavaScript interacting with Cascading Style Sheets (CSS) and web documents (written in HTML) to create seemingly dynamic pages. Parts of the page had to fly around and zoom out and in, every element on the page needed to react when the visitor passed over it with the mouse cursor, and we invented a new way of web navigation every week. While all this was great fun and a technological challenge, it did not help visitors much.

The “wow” effect lost its impact rather quickly, especially when their browsers were unable to support it and they ended up on a page that was a dead end for them. As DHTML sounded like a great term, it did bring out a kind of elitism: JavaScript developers who were “in the know” did not bother much with keeping the code maintainable, as anybody who didn’t understand the art of making things move was not worth changing their code for in any case. For freelance developers, it also meant a steady income, as every change had to be done by them.

When the big money stopped coming in, a lot of this code got thrown out on the Web for other developers to use, either as large JavaScript DHTML libraries or as small scripts on script collection sites. Nobody bothered to update the code, which means that it is unlikely that these resources are a viable option to use in a modern professional environment.

Common DHTML scripts have several issues:

• JavaScript dependence and lack of graceful degradation: Visitors with JavaScript turned off (either by choice or because of their company security settings) will not get the functionality, but elements that don’t do anything when they activate them or even pages that cannot be navigated at all.
  
• Browser and version dependence: A common way to test whether the script can be exe-cuted was to read out the browser name in the navigator object. As a lot of these scripts were created when Netscape 4 and Internet Explorer 5 were state-of-the-art, they fail to support newer browsers–the reason being browser detection that doesn’t take newer versions into account and just tests for versions 4 or 5.
  
• Code forking: As different browsers supported different DOMs, a lot of code needed to be duplicated and several browser quirks avoided. This also made it difficult to write modular code.
  
• High maintenance: As most of the look and feel of the script was kept in the script, any change meant you needed to know at least basic JavaScript. As JavaScript was developed for several different browsers, you needed to apply the change in all of the different scripts targeted to each browser.
  
• Markup dependence: Instead of generating or accessing HTML via the DOM, a lot of scripts wrote out content via the document.write directive and added to each document body instead of keeping everything in a separate–cached–document. All of these stand in a stark contrast to the requirements we currently have to fulfill:
  
• Code should be cheap to maintain and possible to reuse in several projects.
  
• Legal requirements like the Digital Discrimination Act (DDA) in the UK and Section 508 in the US strongly advise against or in some cases even forbid web products to be depen-dent on scripting.
  
• More browsers, user agents (UAs) on devices such as mobile phones, or assistive tech-nology helping disabled users to take part in the Web make it impossible to keep our scripts dependent on browser identification.
  
• Newer marketing strategies make it a requirement to change the look and feel of a web site or a web application quickly and without high cost–possibly even by a content management system.

There is a clear need to rethink the way we approach JavaScript as a web technology, if we still want to use and sell it to clients and keep up with the challenge of the changing market. The first step is to make JavaScript less of a show-stopper by making it a “nice to have” item rather than a requirement. No more empty pages or links that don’t do anything when JavaScript is not available. The term unobtrusive JavaScript was christened by Stuart Langridge at http://www.kryogenix.org, and if you enter it in Google, you’ll end up on an older self-training course on the subject by me.

Unobtrusive JavaScript refers to a script that does not force itself on users or stand in their way. It tests whether it can be applied and does so if it is possible. Unobtrusive JavaScript is like a stagehand–doing what she is good at backstage for the good of the whole production rather than being a diva who takes the whole stage for herself and shouts at the orchestra and her col-leagues every time something goes wrong or is not to her liking. Later on, the term DOM scripting got introduced, and in the aftermath of the @media conference in London 2004, the WaSP DOM Scripting Task Force was formed. The task force consists of many coders, bloggers, and designers who want to see JavaScript used in a more mature and user-centered manner–you can check out what it has to say at http://domscripting.webstandards.org.

As JavaScript did not have a fixed place in common web development methodologies–instead being considered as either “something you can download from the web and change” or “something that will be generated by the editing tool if it is needed”–the term “behavior layer” came up in various web publications. JavaScript As “the Behavior Layer” Web development can be thought of as being made up of several different “layers,” as shown in Figure 3-1.

Figure 3-1. The different layers of web development

• The behavior layer: Is executed on the client and defines how different elements behave
  when the user interacts with them (JavaScript or ActionScript for Flash sites).
  
• The presentation layer: Is displayed on the client and is the look of the web page (CSS,
  imagery).
  
• The structure layer: Is converted or displayed by the user agent. This is the markup
  defining what a certain text or media is (XHTML).
  
• The content layer: Is stored on the server and consists of all the text, images, and multimedia content that are used on the site (XML, database, media assets).
  
• The business logic layer (or back end): Runs on the server and determines what is done with incoming data and what gets returned to the user.