Section II.2. Standards-Compatible DHTML

II.2. Standards-Compatible DHTML

The roster of well-known browsers that unreservedly aim for standards compatibility is a long one. There is scarcely a Web developer alive who hasn't heard of brand names such as Mozilla, Firefox, Netscape, Safari, and Operaor at least you should be seeing these names in web server logs and reports. Although current products bearing these five browser brands are built on three different engines (all but Opera's engine being open source), they share a high degree of DHTML compatibility for common tasks.

Historically, it was the Mozilla effort to replace the once-popular Netscape 4 browser with a more modern implementation that led to support in its Gecko layout engine for more HTML, CSS, and DOM features than any other browser at the time (2000). Mozilla's engineers made some difficult, but ultimately correct, decisions to abandon old ideas that didn't catch on and approach the browser's internal mechanisms anew.

Developers making the transition to the new world of the W3C Document Object Model (DOM) had to learn an entirely new vocabulary and way of thinking about the objects inside a document. Those who had learned only the IE-proprietary way of modifying a page's content on the fly had to take notice of the W3C DOM's new abstract object model. Even though some W3C DOM features had been implemented in varying stages of IE during the Version 5 and 5.5 lifetimes, content authors had little imperative to switch over, because the Microsoft model was the only one needed to work with IE's DHTML capabilities. Even Opera at the time adopted IE's basic DHTML model. But with the W3C DOM being the only route available for scripting Mozilla's Gecko engine and the perceived "correctness" of following standards, developers had to get to know the terminology and concepts that had not existed prior to the W3C standard.

II.2.1. Simple Element Object References

Perhaps the most vital activity that DHTML scripts perform is modifying the content or appearance of an HTML element object in the current document. The specific way to reference an element depends on how much information your script knows about the desired element. Ideally, an element has an identifier assigned to its id attribute. Armed with that information, your script can use the core document object method whose sole parameter is a string identifier for the desired element:

 document.getElementById("elementID") 

This method slices through the node containment hierarchy of the document's content (as discussed at length in Online Section V), and returns a reference to the first element object in source code order whose id attribute value matches the method's argument. This syntax is also implemented in IE 5 and later.

It's unfortunate that a method that is likely to get a lot of use in scripts is so long and difficult to type (observe the case of each letter). Some scripters include a helper function in every page whose name is short and sweet, allowing repeated access to the method to save some bytes along the way:

 function getEl(elemID) {    return document.getElementById(elemID); } 

One other DOM object method can come in handy if you need to reach a series of elements that share the same tag:

 document.getElementsByTagName("tagname") 

This method returns an array consisting of references to each element whose tag matches the name supplied as an argument. Importantly, this method can be applied to any HTML element object, whether or not it acts as a container of other elements. Thus, you can use the method to obtain, for example, references to all p elements inside a div container whose ID is sidebar:

 var elemList = document.getElementById("sidebar").getElementsByTagName("p"); 

Thereafter, you can loop through the array to obtain a reference to each p element in turn.

One other point about the W3C DOM specification: it continues to recognize the contribution of the first scriptable browser DOM, with its limited range of objects, such as forms and form controls. The "old" way of referring to these objects, such as document.forms[n].elements["controlName"], is still valid syntax. In practice, however, you should use only this "Level 0" syntax when scripts need to be backward-compatible with earlier browsers.

II.2.2. Cascading Style Sheets

CSS supporters in the developer community have been vocal in their demands of browser makers to support as much of the CSS2 standard as possible (and in a uniform waynot always an easy proposition, it turns out). Mainstream standards-compatible browsers available in 2006 support all of CSS1, most modules of CSS2, and, in some cases, preliminary features of CSS3. Script access to style sheet properties occurs via an element object's style property. This property contains a style object whose properties correspond to style sheet properties. Important: the W3C DOM standard specifies that an element object's style property reflects only the style attribute values of an element, and not style settings made elsewhere in the document. To reach the details of style properties affecting an element, regardless of their source (e.g., linked in from an external .css file), the W3C DOM provides a somewhat convoluted construct to read what is known as the computed style. This feature, implemented starting with Mozilla 0.9.2, Safari 1.3/2.0, and Opera 7.5, is demonstrated in Online Section IV.

II.2.3. Positioning and Layering

Although CSS-P (positioning) was not strictly a part of the CSS specification until CSS2, the properties associated with this capability have been built into mainstream browsers since the days of Netscape 4 and IE 4. These and later browsers support style sheet properties that place elements in their own layers above the body content. An inline style rule that pulls a graphic out of the rendering sequence of a page and positions it to a specific spot within a document looks as follows:

 <img src="/books/2/570/1/html/2/myFace.jpg" height="60" width="40" alt="Nancy's Mug" style="position: absolute; left: 200px; top: 100px"> 

Positioning properties include facilities for hiding and showing an element, as well as controlling the stacking order of the layers.

In standards-compatible browsers, dynamic positioning that acts in response to user actions must use the W3C DOM event model, which is different from the IE event model. Even so, the two can be made to work together without too much difficulty, as described in Online Section VI.

II.2.4. Dynamic Content

Drafters of the W3C DOM standard produced a system that provides a high level of conceptual consistency for the way scripters modify portions of a document's content. This was done, however, at the expense of simplicity (compared to the ways scripters were accustomed to in Internet Explorer's proprietary object model).

The easiest content to modify is text that is contained by an element. Such text is represented in the DOM as the value of a text node nested with the element, and is handled through strings in JavaScript. But when it comes to modifications involving elements, the W3C DOM approach gets a bit wordy. To create a new HTML element and its content in pure W3C DOM syntax requires the following sequence:

1. Create an empty element for the desired tag with the document.createElement( ) method.

2. Assign values to its individual attributes one at a time, preferably via the element's setAttribute( ) method.

3. Create a text node for the element's content with document.createTextNode("newtext").

4. Use a variety of node methods to construct the node tree of the new element and its content.

5. Use another method to insert the new node group into a position within the document's existing node tree.

If the content your scripts need to generate has lots of elements and text nodes, the sequence requires many more statements. The concept of creating an empty object, populating its attributes or properties, and then inserting the object into its rightful place permeates the W3C DOM, and not only for document content. The phrase "Create, Populate, Insert" will become your mantra.

Engineers at Mozilla and elsewhere recognized, however, that developers found some Microsoft proprietary DOM features to be very convenient. As a compromise to practicality over blind adherence to the standards, most modern browser engines implement the IE innerHTML property for any element. This allows scripts to assemble new content as if it were a string of HTML source code to be inserted where desired. Online Section V will compare these approaches in detail.

II.2.5. The XMLHttpRequest Object

In response to the popularity, utility, and broad browser support of Microsoft's XMLHttpRequest object (originally implemented in IE as an ActiveX object), the W3C opened up a working group to standardize the operation of this object. This object, at the core of what has become a new generation of web-based applications (e.g., Google Maps and highly interactive web email pages), allows a web page to communicate with a server asynchronously in the background. That is, after the page has loaded, a script can request subsequent data from the server (and submit data, as well) without interfering with the content of the current page. Data returned from the server (which can be in XML format) can then be parsed by scripts to modify existing content on the page.

Mozilla-based browsers were the first outside of IE to add this object for mainstream browsers. Safari 1.2 and Opera 8 eventually followed. Because all of these implementations operate on non-Windows operating systems, the XMLHttpRequest object is a full global object, rather than an ActiveX object. In fact, Microsoft even went so far as to build the object into its global objects for Internet Explorer 7, thus allowing the same basic code to work across browsers.

II.2.6. The Event Model

Events are the critical bridge between user action and scripted activity. Virtually every element object has events that can be scripted to respond to user and system actions. For example, it is possible to associate different actions with user clicks over different headings (even if the text blocks don't look like links) by assigning a different script statement to each heading's click event.

The W3C DOM Events module introduced some new terminology for scripters already experienced with DHTML scripting in earlier browsers. Elements are instructed to respond to a type of event by assigning an event listener to it, meaning that scripts instruct elements to "listen" for events of particular types, such as mouse clicks, key presses, and so on. When an element "hears" that event type, processing shifts to a function, just like the event handler functions you are used to.

An event object contains numerous properties about the details of the current event being processed. An event listener's function receives the event object as a function argument.

An important aspect of the event model you need to understand is event propagation. An event, unless otherwise instructed by script, continues to "bubble up" through the HTML element containment hierarchy of the document. Consider the following simple HTML document:

 <html>   <body>     <div>       <p>Some Text:</p>       <form>         <input type="button" value="Click me" onclick="alert('Hi!')">       </form>     </div>   </body> </html> 

When the user clicks on the button, the click event is first processed by the onclick event handler in the button's own tag. Then the click event propagates through the form, div, and body elements. If the tag for one of those elements were to have an onclick event handler defined in it, the click event from the button would trigger that handler, too. Event bubbling can also be programmatically canceled at any level along the way.

Events also trickle downward through the hierarchy in the W3C DOM event model. To process an event on its way to its actual target, however, a script must instruct an event listener to capture the event. Online Section VI describes event propagation in more detail.

One area in which the W3C DOM model is much more conservative than the IE model is in the breadth of event types. Because the W3C model is not operating-system-dependent, it has so far settled on a basic set of events that let scripts work with common mouse and system events. The module specifying keyboard event details in DOM Level 3 has not been finalized as of late 2006, but browsers support a preliminary version that was originally part of Mozilla.

II.2.7. Operating System Support

It's not uncommon today to find browser engines designed outside of operating system companies to be written such that the same underlying engine is used for all OS versions of the browser. Such is the case with Mozilla's Gecko engine and Opera's Presto engine. All operating system versions of Firefox, for instance, are derived from the same core browser-engine code base. A principal benefit of this approach is that all DHTML-related rendering and activity tend to operate identically, regardless of operating system.

Another aspect of this consistency is that web page user interface elements are not as operating-system-dependent as previous versions. Designs for buttons and other standard UI elements are not controlled entirely by the operating systems, but, in the case of Mozilla-based browsers, rather by definitions associated with the current theme (or "skin") in force at any moment. Default buttons, for instance, generally render with the same dimensions and proportions in all operating system versions. Unlike the earlier days of graphical user interfaces on personal computers, the multiplicity of web designs seems to have reduced the clamor for absolute UI consistency across applications for a given operating system (Macintosh users were particularly sensitive to this type of consistency). Today, as long as users can distinguish a checkbox from a radio button, or intuitively detect a clickable button, the design passes muster. The upside for web developers is that pages using standard elements are more likely to resemble each other on all operating system platforms.