II.3. Internet Explorer DHTMLThe browser that first inspired extensive dynamic content was Microsoft Internet Explorer 4. Although they are considered basic features of today's DHTML browsers, two groundbreaking characteristics of IE 4 fired developers' imaginations at the time:
In the absence of an industry standard for its document object model during IE 4's development, Microsoft invented its own model, along with a vocabulary of objects, properties, methods, and object collections (arrays). Then, as the radically different W3C DOM recommendation started taking shape, and with so many scripts "in the wild" relying on the IE 4 model and syntax, Microsoft faced the unenviable task of blending the W3C model into its IE 4 model. The transition began slowly in IE 5 (although the independently developed IE 5 for the Macintosh embraced more of the W3C DOM from the start) and gradually picked up the pace through Version 6 (with little new in the DOM department for Version 7). This means that for many object-scripting tasks in IE-only applications, you have your choice of the Microsoft or W3C DOM approach in your codean 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 as your primary focus, 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 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. This will lead to pages and applications that won't perform as expected when you expand your audience to other browsers.
II.3.1. Element Object ReferencesAll 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") 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 lets you omit the document.all part of a reference so that you can 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. This capability (also supported in Mozilla 1.7 only in quirks mode, Safari 1.3/2.0, and Opera) has another potentially dangerous side effect: Because element ID names become global object identifiers, it means that you cannot use any element ID on the page as a scripting identifier for variables, functions, arrays, or other objects defined in the global space. Unless you must explicitly support IE 4, you should avoid the document.all reference format in your DHTML code. The W3C DOM document.getElementById( ) method is supported by an overwhelming majority of scriptable browsers in use today, including IE 5 and later. Most code examples in this book assume the W3C DOM style of element object referencing. II.3.2. Cascading Style SheetsSome CSS functionality was introduced in IE 3, but IE 4 was 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 and substantial CSS2 support for IE 7. Web developers frequently criticized Microsoft for its CSS implementations through IE 6. In response, the IE 7 team focused intently on CSS compatibility. Script access to CSS properties occurs via an element object's style property. This property contains a style object whose properties correspond to CSS style sheet properties. 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. II.3.3. Dynamic ContentRendering engines in IE 4 and later respond quickly to changes in content, by reflowing the page after any such change (without reloading the page from the browser or cache). 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. The original Microsoft approach was to treat an HTML document as a character string that could be modified by inserting, deleting, or replacing chunks of text (including tags, if necessary) within the document. Some developers continue to find it easier or more convenient to use IE's string manipulation properties (such as innerHTML) to modify elements and their content, rather than the W3C DOM node notation. In fact, the innerHTML property has become a de facto standard that is supported by most DHTML-capable browsers, including Safari, Opera, and those based on Mozilla. Be prepared, however, to have your code criticized by developers who prefer a purer implementation using only W3C DOM syntax and node concepts. Also be aware that excessive string manipulation tends to be a performance hog in JavaScript. II.3.4. The XMLHttpRequest ObjectInternet Explorer 5 offered the first opportunity for a web page to retrieve XML data from a server, and make the XML document available to scriptsall in the background. For IE 5, 5.5, and 6, the capability was loaded into the document as an ActiveX object. Once an instance of the object was created, scripts could send data to a server (with GET or POST methods), including data in the form of URL extensions or separate data (e.g., a SOAP call consisting of XML). Asynchronous interactivity with a server, coupled with a fully dynamic document object model, allowed for the creation of web pages that more closely simulated working with a standalone application. For example, if a user wants to "drill down" to view more details about an item in a table, a script can request just that little extra data, receive it in XML form, and let a script quickly display that data in a pop-up box or expanded table cell. No more retrieving an entirely rewritten page just to get a tiny bit of updated data. Other browser makers implemented non-ActiveX versions of the object, calling it the XMLHttpRequest object. Microsoft even added support for the native object to IE 7. Fundamental XMLHttpRequest object operations work with the same syntax across all supporting browsers once the instance of the object is created. See Online Section VII for more details on working with the XMLHttpRequest object. II.3.5. The Event ModelMicrosoft was certainly entitled to develop its own event model for IE 4 because there was no industry standard at the time. But unlike its adoption of W3C DOM modules in other areas, Microsoftat least through Internet Explorer 7has refused to implement the W3C DOM event model alongside its proprietary version. Developers have no choice but to code for the Microsoft event model if they want their pages to run in IE. 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 can be scripted to respond to events triggered by user and system actions. IE for Windows, especially starting with IE 5, defines a large number of events that can trigger scripts (as described in Chapter 3 of Dynaminc HTML: The Definitive Reference, the Third Edition). 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. A key part of the IE event model is an event object. This abstract and short-lived entityaccessed as a property of the window object, and thus available to any function processing the eventcontains 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 screen position, keyboard key, and so on. Most events "bubble up" through the HTML element containment hierarchy of the document. Scripts can stop an event from bubbling past any element in the hierarchy. As you will see in Online Section VI, 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 features with the W3C model). II.3.6. Transitions and FiltersBuilding atop the syntactical conventions of CSS1, IE 4 and later for Windows includes a proprietary style property called filter (implemented as an ActiveX module). This property serves double duty. One set of 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 properties 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. II.3.7. Downloadable FontsA 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 properties: <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 old-fashioned <font> tags. Note that a font must be available on the server in a special format generated by a "font object" creation tool. The tool for IE is called Web Embedding Fonts Tool (WEFT), which you can download and learn about at (http://www.microsoft.com/typography/). II.3.8. Data BindingIE 4 and later for Windows provides hooks for ActiveX controls that communicate directly 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). Data binding was, in many respects, a forerunner to the asynchronous server access commonly known today as AJAX. Data binding is, however, specially tailored to accessing server databases directly, whereas AJAX implementations performing the same task typically require further server programming to act as an interface between client requests and the database. 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. II.3.9. Additional Windows-Only FeaturesIE 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 often fail to understand which capabilities will not translate to other browsers. II.3.10. Macintosh VersionsThe Macintosh applications group at Microsoft (based in Silicon Valley, rather than Redmond, Washington) controlled the development of the IE browser for the Mac, separate from the Windows version. One result of the separate development efforts was that the IE/Mac browser had been free to embrace more W3C DOM features in its Version 5 than IE 5 for Windows. Eventually, however, newer browsers available for the Mac, including Firefox and especially Apple's own Safari, overtook IE/Mac in their support for W3C DOM. With Apple devoting so much effort to improving Safari internally, Microsoft stopped further development of IE/Mac. IE/Mac is now rather outdated, but a fair number of Mac users, especially those who cling to Mac OS 9, use that browser. Because of some of its unique behaviorial quirks, that browser can be a problematical one to support with DHTML features. The key point to take away is that IE/Mac was a browser unto itself, and should, therefore, be treated almost as a separate platformone that needs testing of your DHTML work if you intend to support its users. |