 |  |
| |
A primary design goal of the Mozilla browser engine behind Netscape 6 was support for industry standards. Abandoning a large portion of the earlier version code allowed the browser engineers to approach internal mechanisms anew. In the end, the Netscape 6 browser supports far more HTML, CSS, and DOM features than earlier versions. As a driving force behind the core ECMA language specification, the company also assures compliance with that standard. Finally, a brand new rendering engine that reflows dynamic content brought this browser up to the same DHTML expectations as Internet Explorer.
As the basis for most dynamic content scripting, the W3C DOM brought with it a 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 adopted IE's basic DHTML model. But with the W3C DOM the only route available for scripting Netscape 6 and the perceived "correctness" of following standards, content authors had reasons to get to know the terminology and concepts that had not existed prior to the W3C standard.
The close association between Netscape 6 and standards sometimes makes it difficult to separate the two efforts. But keep in mind that both tracks are still evolving at their own paces, and it is generally easier to add features to a standard than it is to produce a new browser release that implements those features. The browser that supports 100% of all current standards' requirements does not exist and most likely will never exist, unless the standards stop evolving for a few years. The Netscape 7 browser implements only a handful of new DOM items not already supported in Netscape 6. Except as noted in Chapter 9, you can regard Netscape 7 as a more mature, tested, and bug-fixed version of Netscape 6.
Netscape 6 of course continues support for the old Level 0 DOM syntax, so that users can avail themselves of scripts written for older browsers. But for DHTML features, the new node-based W3C DOM terminology is required. The predominant syntax is via the finger-twisting method of the core DOM module:
document.getElementById("elementID")This method slices through the node containment hierarchy of the document's content (as discussed at length in Chapter 5), 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.
Netscape 6 supports all of CSS1 and substantial parts of CSS2 that apply to visual browsers. Scripted access to element styles occurs through the same style property that is also a part of the original IE 4 DOM. The W3C DOM standard specifies that the 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, the W3C DOM provides a somewhat convoluted construct to read what is known as the computed style. This feature was first implemented in Netscape 6.1 and is demonstrated in Chapter 4.
Having abandoned the Navigator 4 proprietary <layer> tag and corresponding nested layer object architecture, Netscape 6 provides full support for the CSS-based positioning attributes. This act brings the Netscape browser in sync with the way IE 4 and later permit scripts to adjust positioning, visibility, and stacking order of elements via their style properties. Moreover, the positioning styles can be applied directly to elements of any kind, rather than having to embed content into span or div elements unless you wish to group multiple elements inside a single positioned container. 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 Chapter 6.
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.
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, 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:
Create an empty element for the desired tag with the document.createElement( ) method.
Assign values to its individual attributes one at a time, preferably via the element's setAttribute( ) method.
Create a text node for the content with document.createTextNode("newtext").
Use a variety of node methods to construct the node tree of the new element and its content.
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.
Netscape recognized, however, that developers found some nonstandard, IE DOM features to be very convenient. As a compromise to practicality over blind adherence to the standards, the Mozilla DOM engine implements 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. Chapter 5 will compare these approaches.
Separately, table elements benefit from a series of methods and properties—shared with the IE model—that make radically dynamic tables easily scriptable. The regularity of table rows and cells encourage the use of tight loops to repopulate a table with new or sorted data from JavaScript arrays or XML data (see Chapter 5).
The W3C DOM Events module introduced some new terminology for scripters already experienced with DHTML scripting in earlier browsers. Event handlers became known as event listeners, meaning that scripts instruct elements to "listen" for events of particular types, such as 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. Interestingly, the environment for the W3C DOM event object more closely resembles the defunct Navigator 4 event model. An event listener's function receives the event object as a function argument (in contrast to the window-based object in the IE event model).
Event propagation is modeled after both the IE and Navigator 4 event models. The default propagation model allows events to bubble upward through the element containment hierarchy, as described earlier for the IE model. But events also trickle downward through the hierarchy. To process an event on its way to its actual target, however, a script must instruct an event listener to capture the event. Microsoft also added the event capture option to its event model for IE 5, so the two models can be made to work very much like each other, despite major discrepancies elsewhere.
One area in which the W3C DOM model is much more conservative is in the breadth of event types. Because this 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. Due to international character set intricacies, keyboard event details are not part of DOM Level 2, but Netscape 6 implements the basic events that are likely to be compatible (or not conflict) with the finished specification for DOM Level 3.
All operating system versions of Netscape 6 are derived from the same core browser-engine code base. A principal goal of this approach is that all DHTML-related rendering and activity is to operate identically, regardless of operating system. Netscape has achieved remarkable consistency across operating system versions of the browser.
Another aspect of this consistency is that the user interface (implemented in an XML format called .xul) is not as operating-system-dependent as previous versions. Designs for buttons and other standard UI elements are not controlled by the operating systems, but 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, the multiplicity of web designs seems to have reduced the clamor for absolute UI consistency across applications for a given operating system. 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.
|  | |
| 2.3. Internet Explorer DHTML |  | 2.5. Other Browsers |
Copyright © 2003 O'Reilly & Associates. All rights reserved.