Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Web Design & Development > Usability

Web Design Reference Guide

Hosted by

Client-Side Interactivity

Last updated Oct 17, 2003.

By Molly Holzschlag

Interactivity on the client side taps into the intelligence of Web browsers and related plug-ins to accomplish the goal. In the case of client-side interactivity, the user must have support for the technology in order for the interactivity to work. This is one of the primary disadvantages of client-side interactivity in certain instances, as you'll soon see.

Browser Techniques: Scripting and the Document Object Model (DOM)

As Web browsers began to compete for market share, one of the areas of great activity in terms of development was within the way scripting was being developed and used.

Because of the so-called "browser-war" years when Netscape and Microsoft were duking it out for dominance, an unfortunate split occurred which has been disabling for designers in so many ways. This split, which is of course seen in the context of browser support for CSS and proprietary technologies, also occurred within the scripting mechanisms that browsers provided.

The first concern arises when we examine the Document Object Model, referred to fondly as "The DOM." This is an interface within Web browsers that allows scripting to interact with individual HTML elements in HTML and XHTML documents. So the DOM provides the bridge from a scripting language, which can help make events occur, to the actual element such as a paragraph, a list, or a set of links to modify them in some way.

The DOM is a standard that is overseen by the W3C. However, as we all know by now, just because there's a standard available in the Web design world doesn't mean that browser developers or Web designers employ them. In the case of the DOM, the differences between the two browsers split the Web into two harsh camps: those that could use the dynamic scripting available in Microsoft IE, and those that could use the scripting available in Netscape.

Of course, the languages used to access the DOM are different, too. Netscape started with LiveScript, which eventually became JavaScript. Microsoft used its own scripting language, VBScript (Visual Basic Script), and its own version of JavaScript, known as JScript. Efforts to standardize this issue have been underway for a long time as well, and we end up with something called ECMAScript, a standardized form of JavaScript.

But despite this turmoil, an approach to client-side interactivity was emerging that utilized these various browsers and browser technologies. The approach is familiarly known as DHTML, or Dynamic HTML.

The name is a bit of a misnomer because DHTML is not a language in and of itself. It is, however, an interactive browser scripting methodology that uses a combination of the following technologies:

  • DOM

  • Scripting (JavaScript, VBScript, ECMAScript)

  • Cascading Style Sheets (CSS)

  • HTML or XHTML

During the times of greatest turmoil, DHTML was split into browser camps. With better browser support for standardized DOM and scripting, along with increasing awareness as to how to use HTML, XHTML, and CSS according to standards, creating dynamic events within the browser has become significantly easier, although not without difficulties.

By using the DOM and tapping into the power of scripting to modify HTML elements, Web designers can add a variety of interactivity to their Web pages, including the following:

  • Browser "sniffing" and redirection

  • Pop-up windows for interactive menus and forms

  • Rich, dynamic menus with rollover and drop-down effects

  • Visual effects and animation within the page

  • Customization of page elements (such as dragging and dropping page elements within a page)

All these techniques, and many more, can be achieved using a variety of scripting and DOM techniques—all within a supportive Web browser, and without ever having to return to the Web server to gain additional processing instructions.

HTML and XHTML Forms

Forms built using HTML could probably be considered the first sophisticated interaction available on the Web. But forms actually exist in a middle ground between client- and server-side interaction. The reason they're grouped under client-side, at least for the purposes of this discussion, is that simple forms require very little processing from the server—most of the detail of the simple forms you'll work with will be within the context of HTML elements (see the Forms section for more information).

Forms can be as simple as allowing someone to input information and receive a "Thank You" response, and their information is emailed along. This is the most common type of form—you see it on just about every Web site's contact page.

But forms are used for a wide range of applications. They are in and of themselves interactive because the user inputs information and is then provided something in return. Sometimes, however, forms are embedded within deeper interactive processes. For example, you might be on the same portal page, as discussed earlier, and there are numerous instances of forms embedded into the interface. Each form has a different expected result and is used for a different purpose.