10.0 Introduction

No web page is (or should be) an island. Just as there is a way to reach the page, so should there be one or more ways to navigate to other destinations, either within the same site or outside. The HTML hyperlink element—embedded in pages as the rather nondescript <a> tag—is the conventional, nonscripted way to provide a clickable avenue for the user to navigate to another page. But more sophisticated user interface designs frequently require Dynamic HTML to assist with the presentation of navigation options and the very act of navigating.

10.0.1 The location Object

Each window (and frame) object in every scriptable browser has a location object whose properties contain information about the URL of the page currently loaded into the browser. This is an abstract object, meaning that the object has no particular physical presence visible on the page—except perhaps the URL that appears in the browser's Location or Address field. But the location object does not control what the user sees in the Location/Address field unless the browser succeeds in navigating to a page you assign to the location object.

Properties of the location object are read/write. The individual properties reveal components of the URL (and even the entire URL) of the loaded page. Without any restrictions to this information, however, scripts could spy on your browser activity without you knowing it. For example, imagine entering an unscrupulous web site that looks like the Google search page. In fact, you could be viewing the actual Google search page within a frameset whose second frame is hidden from view. A script in the framesetting document or the other frame could inspect the location object of the visible frame every ten seconds, accumulating a record of every page visited in that frame. The information could then be sent back to the spoofer's server without the user's knowledge or permission.

Despite the fact that, in some situations, knowing the URL of another frame or window could enhance the user experience, the potential for invasion of privacy has forced browser makers to clamp down on the reading power of location object properties. Browsers observe various types of security policies to help protect a user's privacy. The policy that applies to the location object is known as the same origin policy. If a script running in a page served by one server and domain wishes to inspect the location object of another frame or window, the document in the other frame or window must also be served by the same server and domain. If the user navigates in one of the frames to another domain or server, the same origin policy fails (even though the frameset is still served within policy), and the location information is not accessible to the other frame.

Partially as a result of a variety of security holes in Internet Explorer for Windows, Microsoft occasionally clamps down so tightly on a potential threat that attempts to read location object properties of another window or frame—even from the same origin—result in a security-related script error (such as "Access denied."). From a reliability standpoint, reading the location object is best done in the same page as the script doing the reading. As you'll see in a few recipes in this chapter, there are some good reasons to do this.

All this security stuff, however, applies only to reading the location object's property values. You can assign new values to the properties across window and frame boundaries with impunity.

10.0.2 Passing Data Between Pages

A very common model in the web-application world is essentially a forms-based navigation system, in which virtually every page is a form whose values are submitted as a way to progress to the next page. When the submitted form reaches the server, programming on the server dissects the form controls' name/value pairs. Some of the pairs may get shunted off to a backend database. Other bits may be reformulated as values of hidden input elements in the page that gets assembled for return as the next page. Once the second page is served up, the server doesn't know whether the user is still connected to the site or has perhaps navigated off somewhere else. In other words, the server simply reacts to requests from a browser, returning a page in response.

The server may be programmed to keep some temporary information about the user on hand, identified by a session ID. That session ID is passed down to the browser with each returned page so that when the next request arrives, the server program can tie together requests that come from a single browser. Some server programs that assemble pages on the fly for each visitor (such as amazon.com) populate the href attributes of all intrasite links with the session ID so that the server can keep passing the ID along from page to page. It may sound a bit crude, but it is much more bandwidth-efficient than maintaining a full-time connection between server and browser (or between thousands of browsers at any instant for a popular public site).

However, not everyone has the requisite programming skills or server access to accomplish this server-based way of passing along live information from one page to another. By the same token, security restrictions in browsers prevent the random reading and writing of data to the local hard drive of users. Fortunately, with the help of JavaScript and various pieces of the object models, you do have a few different ways to get information from one page to another without having to involve the server. Recipe 10.4 through Recipe 10.6 show these approaches using cookies, frames, and URLs. For example, consider the case in which a user has bookmarked just one content page from a frameset whose other frames provide vital site navigation tools. If the user loads the bookmarked page into the browser, a simple script in that page can make sure that not only the complete frameset loads, but also that the bookmarked page appears in the content frame, rather than the default pages of the frameset.

10.0.3 Pop-Up/Drop-Down Navigation Menus

Navigation menus that pop up or drop down from some steady user interface element (such as a pseudo-menu bar or tab) are incredibly space-efficient. Rather than list dozens of choices in a navigation panel on a page, only top-level categories are visible by default. Rolling the mouse over one of the category names makes a nested list of relevant destinations suddenly appear out of the ether. This is a user interface concept that all Windows, Mac, and X Window System users can readily identify and know how to use.

Every DHTML guru and his cat has created a menuing system that takes advantage of element visibility and positioning in Version 4 browsers and later. I don't know if the world needs yet another pop-up menu system, but a DHTML cookbook would not be complete without one. One insurmountable hurdle is that a single design cannot fit all situations. Every site designer has a different look in mind when envisioning a menu system, and design requires far more fiddling with cookbook-style code than applying a different style sheet set. The goal, then, is not to create a be-all, end-all menuing system. Instead, focus on producing standards-compatible code for as simple a system as possible (using a DHTML library described more fully in Chapter 13), which is flexible enough to be tweaked for lots of different looks and situations.

Before you decide to deploy a pop-up menu system, especially in a public site, be sure to treat it as a value-added interface element, rather than as a mission-critical element. You should make it possible for a user with JavaScript disabled or unavailable to navigate through your site, even if it requires one or more extra page loads to reach the destinations listed in the pop-up menus. By relying on traditional links for nonscripted backup navigation, you also assure that search engine spiders and bots will be able to reach the inner depths of your site and index those pages as well.

10.0.4 Default Data Delivery to a Page

Some of the recipes in this and subsequent chapters rely on a body of unseen data being accessible to the page's scripts. Depending on your specific application, the data may be static, or it may be dynamic data pulled from a database and assembled into a form suitable for download to the browser.

Until recently, there wasn't much choice in how this data would arrive to the browser: it was in the form of JavaScript objects or arrays (see Recipe 14.5) hardwired into .html pages on the server or blended into server-generated page content on the fly. Some of the newer browsers, notably Internet Explorer 6 for Windows and Mozilla-based browsers (e.g., Netscape 6 and later), provide facilities for downloading XML data files into unseen virtual documents. Scripts in the main page may then access the XML data using DOM standards-based document tree-access techniques (see Recipe 14.4). With more and more database data being stored and easily delivered in XML format, this latter technique is undoubtedly the wave of the future. It may take some time for the critical mass of typical web-surfing browsers to be capable of downloading straight XML data, so don't feel pressured into adopting this approach immediately for a public site. But for intranets whose installed browsers already support XML data, the XML option should be appealing now.