Scripting for IE 5 Macintosh Edition

Alexander Pope may have been only half-correct when he wrote, "A little learning is a dang'rous thing." A Web developer who has mastered the massive Microsoft Internet Explorer Document Object Model (DOM) for the PC may, in truth, have too much learning when it comes to writing scripts that are compatible with Macintosh versions of Internet Explorer (IE).

Windows-centric developers might expect compatibility problems with non-Microsoft browsers, such as Netscape Navigator, Opera, and others. What trips up many developers, however, is that the IE/Windows DOM includes many proprietary features that rely on the internal architecture of IE/Windows and the Windows operating system. Microsoft's Web developer documentation doesn't always highlight the features that are not available in the Macintosh version of Internet Explorer. This article will show Windows-centric IE developers what they can expect from the Macintosh version of the Microsoft browser.

How We Got Here

Internet Explorer 4 significantly advanced the concept of the DOM. Previous versions of the DOM provided scripting access to a very limited set of elements in an HTML page. While IE4 maintained backward compatibility with older versions of the DOM, this browser version was the first to treat every HTML element on the page as a scriptable object. Changes to an element's content were reflected instantly with the help of an automatically reflowed page that moved surrounding content around a modified element. A new way of addressing an element object came by way of the document.all collection -- an array of all HTML element objects on the page. Assign an identifier to an element's ID attribute, and your scripts could reach that object through the syntax:

document.all.elementID

Or, because the document.all collection is always implied in IE, simply:

elementID

The IE4 DOM included scripting control of Cascading Style Sheets (CSS) for both Macintosh and Windows versions. However, the IE4 DOM also included several documented features that worked only in the Windows version of IE. More on these issues in a moment.

While IE4 for Windows and Macintosh tempted the world with true dynamic content (Netscape Navigator 4 was still saddled with a static page that, at most, could have layers of HTML content float dynamically above the static page), the World Wide Consortium (W3C) assembled a public standard for a DOM that applied to both HTML and XML content. The W3C DOM was backward compatible with the original DOM (referred to as Level 0), and it also assumed that a document was as dynamic as IE4 demonstrated it could be. So as not to step on existing code, the W3C DOM developed a rather distinct syntax for addressing an HTML element object and its content with scripting statements. For any HTML element that has an identifier assigned to its ID attribute, the reference to the element requires a new method of the document object:

document.getElementById("elementID")

For more on these methods and the W3C DOM, read to these twoarticles on the subject.

Microsoft faced a dilemma. On the one hand, developers for IE4 had already invested heavily in the IE4 style of referencing objects; on the other hand, Microsoft had participated in the W3C DOM effort and could not ignore it. The result, as implemented in IE5, is a hybrid model that maintains compatibility with the IE4 DOM and supports at least the basic way of referencing objects in the W3C DOM syntax. Redundant? Yes.

We sometimes forget that the Windows development team doesn't work that closely with the Mac team at Microsoft. What differences have you encountered concerning how the two versions (Mac/Win) of IE render Web pages?Post your comments

In fact, scripters who have grown comfortable with the document.all approach to addressing elements have wrenching decisions to make as the installed base of W3C DOM-compatible browsers begins overtaking that of the Internet Explorer 4 world. The natural tendency is to keep all existing code running as long as possible, adding as few tweaks as are necessary to make scripts run in browsers that support only the W3C DOM. For newly created applications, however, you may be tempted to work with the W3C DOM syntax (e.g., using document.getElementById() rather than document.all) for the growing list of browsers that support the syntax (such as IE5+ for Windows and Mac, Netscape 6, and Opera 5). And yet your server logs may indicate that a substantial number of visitors still use IE4. It may be too soon to jetison document.all entirely as a way to reference element objects.