 |  |
| |
The browser that inspired extensive dynamic content was Microsoft Internet Explorer 4. Two groundbreaking characteristics of that browser fired developers' imaginations:
Exposing practically every HTML element as a scriptable object
Automatically reflowing the page after content modification
In the absence of an industry standard for its document object model, Microsoft invented its own model, along with a vocabulary of objects, properties, methods, and object collections (arrays). While many of the concepts of the IE 4 model found their way into the HTML portion of the W3C DOM recommendation, the W3C crafted an entirely new architecture for its core model, along with its own vocabulary set.
With so many scripts relying on the IE 4 model and syntax, Microsoft faced the unenviable task of blending the W3C model into the IE 4 model. This began slowly in IE 5 (although IE 5 for the Macintosh embraced the W3C DOM more from the start) and gradually picked up the pace through Version 6. This means that for many object-scripting tasks, you have your choice of the Microsoft or W3C DOM approach in your code—an enormous syntactic palette from which to choose. As yet, there are no signs of Microsoft deprecating its own features. If you choose the W3C DOM route, however, you'll find that Microsoft has so far elected to bypass some modules (as described shortly), forcing you to use the Microsoft syntax for some vital services, such as events. On the flip side, if you start your DHTML authoring life exclusively in the world of IE for Windows, you will find some features not available in other browsers, including IE for the Mac.
The breadth of browsers you intend to support for your DHTML content exerts great influence over a key scripting task, namely how your script statements reference HTML element objects. All IE browsers starting with Version 4 (including those for the Mac) implement the document.all collection, which provides a gateway to any element for which you have assigned an identifier to the id attribute. Statements that refer to elements can reference the element ID as either a property reference or string, as in the following forms:
document.all.elementID
document.all("elementID")
document.all["elementID"]
document.all.item("elementID")Even Opera 4 and later, when its Connection preference is set to identify itself to servers as IE, supports the first three formats. The string versions are helpful when you define generic functions that receive an ID string as an argument, allowing a single statement to reference any element.
IE also let you omit the document.all part of a reference so that you could reference an element simply by its ID. Although this practice makes for compact code, it also makes it very difficult to go back to the code to find statements that reference elements. Converting from the abbreviated style to the new W3C DOM-oriented referencing style will be a headache unless you are intimately familiar with the document's element structure and IDs.
If you prefer to bypass support for IE 4, you should use the W3C DOM element reference syntax because in time, it will predominate. In this case, the syntax consists of a core document object method whose sole parameter is a string identifier for the desired element:
document.getElementById("elementID")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). But because this is the accepted standard format, your scripts will be more compatible with a wider range of browsers going forward than with the IE 4 version.
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 Level 0 objects, such as document.forms[n].controlName, is still valid syntax. Therefore, in the IE environment, several element objects give you three ways to reference them. In practice, however, you should use only the Level 0 syntax when scripts need to be backward-compatible with earlier browsers.
Some CSS functionality was introduced in IE 3, but IE 4 is considered the first browser to make a serious attempt at supporting the CSS Level 1 standard. Even so, the support was far from bug-free. Microsoft claims full CSS1 support for IE 6/Windows. In the process, the company implemented fixes for some long-standing deviations from the W3C standard. While the Windows version went through a slow evolution to achieve this point, IE 5 for the Macintosh provides very good CSS1 support. CSS2 support, particularly complex selectors, is still a work-in-progress. The modularization of CSS (see Chapter 7) will allow future IE versions to opt out of supporting modules that don't apply to the browser, such as the aural style attributes, in which case the browser will simply ignore attributes from unsupported modules.
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 attributes. Element object properties provide scripted access to the element's attribute values, and the style property is no different. In other words, the style property reports only those values assigned to an inline style sheet rule. To read the actual style being applied to the element (from a style sheet defined in the head or imported from an external file), IE 5 and later provide a proprietary currentStyle property for all element objects.
Although CSS-P was not strictly a part of the CSS specification until CSS2, IE 4 and later support style sheet attributes 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="myFace.jpg" height="60" width="40" alt="Nancy's Mug" style="position:absolute; left:200px; top:100px">
Positioning attributes include facilities for hiding and showing an element, as well as controlling the stacking order of the layers (with undesirable behavior when a layer contains some form controls). Script control of these attributes provides much of the dynamism in DHTML-enhanced pages.
Rendering engines in IE 4 and later respond quickly to changes in content, by reflowing the page after any such change. Regardless of your choice of element referencing syntax, the DOMs in IE provide properties and methods that allow adding, removing, or modifying content within an element or whole elements and their content. Starting with IE 5, you have your choice of using the IE 4 DOM or W3C DOM properties and methods for modifying elements and their content. If your audience is exclusively IE 5 or later, you can even mix and match your syntax (using document.all references to elements and W3C DOM properties to read or write the element's content). It's good practice, however, to use the DOM properties and methods that are consistent with the element referencing syntax you use. Netscape 6's support for the IE innerHTML convenience property can help smooth your transition to cross-browser support.
The IE event model, which works hand-in-hand with the object model, is the critical bridge between user action and scripted activity. Virtually every element object has event handlers 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 onclick event handler. IE for Windows, especially starting with IE 5, defines a large number of new events that can trigger scripts (as described in Chapter 10). Many of these events are patterned after the kinds of events application programmers use for manipulating Windows-based data and user interface behaviors. As a result, many of these events are available only in Windows versions of IE.
Another part of the event model is an event object. This abstract and short-lived entity—accessed as a property of the window object, and thus available to any function processing the event—contains details about each event that occurs. Scripts operating in response to events can inspect properties of the event object to determine the element responding to the event, the event's location, keyboard key, and so on.
The last aspect of the event model you need to understand is event propagation. Since IE 4, 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 would trigger that handler, too. Event bubbling can also be programmatically canceled at any level along the way.
While the W3C DOM Level 2 contains an Events module, Microsoft has not implemented it as of IE 6 for Windows or IE 5 for the Mac. As you will see in Chapter 6, cross-browser applications must be built to support both the proprietary Microsoft event model and the W3C DOM event model (and, if necessary, the Navigator 4 event model, which shares some important features with the W3C model).
Building atop the syntactical conventions of CSS1, IE 4 and later for Windows includes a style attribute called filter (implemented as an ActiveX module). This attribute serves double duty. One set of attribute parameters supplies extra display characteristics for certain types of HTML content. For example, you can set a filter to render content with a drop shadow or with its content flipped horizontally. The other set of attributes lets you define visual transition effects for when an object is hidden or shown, much like the transition effects you set in presentation programs such as PowerPoint.
A document to be displayed in IE 4 and later for Windows can embed TrueType font families downloaded from the server. You download the font via CSS style attributes:
<style type="text/css">
@font-face {
font-family:familyName;
font-style:normal;
font-weight:normal;
src:url("someFont.eot")}
</style>With the basic font family downloaded into the browser, the family can be assigned to content via CSS styles or <font> tags.
Note that the downloadable font format differs between Internet Explorer and Navigator. Each browser requires that the font definition files be generated with a different tool. The tool for IE is called WEFT, which you can download and learn about at (http://www.microsoft.com/typography/).
IE 4 and later for Windows provides hooks for ActiveX controls that communicate with text files or databases on the server. Elements from these server-based data sources can be associated with the content of HTML elements, essentially allowing the document to access server data without processing a CGI script. IE 5 for the Mac supports this feature when the server data source is a text file (such as a comma-separated or tab-delimited database file). While data binding is not covered in depth in this book, I mention it here because it is one of Microsoft's dynamic content features.
IE for Windows is largely a collection ActiveX controls. As such, the browser can take advantage of numerous ActiveX facilities that come with the browser and some that are components of the operating system. That's the case with filters and data binding with remote databases (through ODBC), described previously. Script control of the Windows Media Player is restricted to IE for Windows, as is the capability to turn the browser into a content-editing application and (with the user's permission) access the filesystem. Developers who learn DHTML initially in the IE for Windows environment need to understand which capabilities will not translate to IE for the Mac or for other browsers.
The Macintosh applications group at Microsoft (based in Silicon Valley, rather than Redmond, Washington) controls the development of the IE browser for the Mac. One result of the separate development efforts is that the IE/Mac browser has been free to embrace more W3C DOM features in its Version 5 than IE 5 for Windows. On the negative side, however, the two browsers can exhibit differences in fundamental rendering that can make precision page layout and scripted DHTML difficult. Many of these differences are noted throughout Part II. The main point to take away from this situation is that developing content that is to play on both Windows and Mac versions of IE should be tested thoroughly on both operating system platforms.
|  | |
| 2.2. Navigator 4 DHTML—Fading Fast |  | 2.4. Netscape 6 (Mozilla) DHTML |
Copyright © 2003 O'Reilly & Associates. All rights reserved.