Scripting for IE 5 Macintosh Edition

by Danny Goodman and Apple Developer Connection

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:


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


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:


For more on these methods and the W3C DOM, read to these two articles 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.

Comment on this articleWe 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.

document.all in Nav 6

You can simulate the document.all collection in Netscape 6 in a variety of ways. For a page whose element structure does not change under script control, you can instruct NN6 to create a document.all property through W3C DOM syntax. The following function, which should execute immediately after the page loads, shows a compact implementation:

function initAll() {
  document.all = (document.all) ? document.all : 
    ((document.getElementsByTagName("*").length > 0) ?
    document.getElementsByTagName("*") : null)
<BODY onLoad="initAll()">

After this function runs, any IE4 or W3C DOM browser provides access to an element object through the document.all.elementID syntax.

The IE5/Mac DOM Implementation

Many are surprised to hear that separate Microsoft teams produce Macintosh and Windows versions of Internet Explorer. This is quite different from, for example, the way Netscape Navigator 6 shares the same core browser engine in all operating systems. One result of Microsoft's approach is that the two browsers are not always on the same release schedule and therefore do not necessarily contain the same DOM features. Moreover, if you compare the resulting DOM implementations in IE5 for Windows and Macintosh, you might conclude that the Mac development team exercises its own discretion when it comes to implementing DOM specifics. The Windows version of the DOM may contain both Microsoft proprietary and W3C DOM syntax for a particular property or method of an HTML element object. In contrast, the Macintosh version may omit the Microsoft proprietary syntax in favor of the W3C DOM version. Overall, IE 5.0 for Macintosh provides more direct support for W3C DOM syntax than even the later IE5.5 for Windows does.

Lest you throw your hands up in the air in despair, take comfort in knowing that you can still count on a lot of basic DOM functionality and syntax implemented in versions of IE for Mac and Windows. For example, in addition to support for the document.all collection, both platforms support the popular set of element object properties that facilitate direct manipulation of page content:innerHTML, innerText, outerHTML, and outerText.

Scripts in both browsers can control style sheet properties by way of an element object's style property. The fundamental IE4 event model is also consistent across both platforms.

In the Version 5 implementations of IE, both the Macintosh and Windows versions support enough of the W3C DOM node object model to be functional. Since the W3C DOM provides syntactically identical access to style sheet properties as the IE4 DOM does, you don't have to learn any new tricks to be compatible in that department. Perhaps the largest omission in the IE5 family is the W3C DOM event listener model, but IE5 for both Mac and Windows continue to support the IE4 event model.

Viewing the compatibility scene from high overhead, it appears as though a lot of code written for IE/Windows would run smoothly under IE/Macintosh -- and it does. But if you let your script writing be governed by all of the syntax devised for the Windows version, you could find yourself in trouble when you get down to the details. It's time to see which Microsoft DOM items are out of bounds once you leave the Windows version.

Win32-Only Technologies

Internet Explorer for Windows bundles numerous ActiveX controls, some of which the browser requires for normal operation. The browser also has instant communication with other ActiveX controls on the client machine, whether the controls are part of the Windows operating system or are downloaded or installed from third parties. What most other browsers treat as "plug-ins" are implemented as ActiveX controls for IE/Windows. Although IE5/Macintosh offers a modicum of support for ActiveX, the controls devised for Windows do not run under other operating systems, nor have IE/Windows built-in controls (such as the basic Web Browser Control, on which many IE/Windows features are built) been implemented as such in IE/Mac.

As a result, a few powerful Windows-only features are not available on the Mac version. These include Data Binding (direct connectivity to server data sources via the Data Source Object), CSS filters (for transition visual effects and text effects), DHTML Behaviors (the action-oriented equivalent to external style sheet definitions), IE 5.5 content editing, executing external commands (via the execCommand()method), and the TextRange object (allowing script control of arbitrary blocks of text independent of their HTML containers).

Admittedly, this is a long list of features not built into IE/Mac. Most of them are also missing from Netscape Navigator 6 on all OS platforms because (with the exception of the similar, but incompatible TextRange object) these features are not part of the W3C DOM standards -- at least not yet. Therefore, if you want to deploy these features on a public Web site's pages, apply them as additive, rather than mission-critical, aspects of the page. For example, you can apply barndoor transitions between pages of your site, but only IE/Windows users will see the effect.

Fewer Event Types

Compared to Explorer 4, versions 5 and 5.5 for Windows nearly double the number of event types that HTML element objects recognize. For instance, several event types in IE5 signal user dragging motions with respect to an element (onDrag, onDragEnd, onDragEnter, onDragLeave, onDragOver, onDragStart, onDrop). Another event group provides script control over cutting, copying, and pasting content (onBeforeCopy, onBeforeCut, onBeforePaste, onCopy, onCut, onPaste). And still another event type (onContextMenu) makes it easy to interrupt the system-produced context (right-click on the Windows mouse) menu and create custom menus.

In contrast, the IE/Macintosh event repertoire stays within the W3C DOM. Thus, you have the range of mouse, keyboard, and system-generated events that you have come to know and love in IE4 and NN4.

Speaking of events, the IE/Macintosh eventobject is a property of the windowobject, just as it is in IE/Windows. In IE5/Mac, however, the eventobject's properties include not only the IE4 properties, but also some W3C DOM eventobject properties, such as event.charCode(character and key codes are not necessarily the same values) and W3C DOM equivalent of event.srcElement).

The Measure of Things

Far more difficult to predict are differences in the ways the Windows and Macintosh versions of IE render HTML elements that are not absolute-positioned and explicitly sized (in pixels). For example, form buttons render very differently on each OS platform, affecting not only the look of the form control, but also the space it occupies on the page. Additional differences in the ways the browsers report page scrolling and event coordinates can yield unexpected results. Complicating the situation even further is that your page's layout or design scheme can influence these differences. This makes it difficult to offer you simple workarounds or golden rules that apply to all designs. Even so, you should be on the lookout for key mismatches.

For one, if you employ element positioning in your page, you should experience little or no problems if you use the styleobject's positioning properties (style.left, style.posLeft,, style.posTop) exclusively in your script manipulation of the elements. Avoid trying to mix and match regular element positions (as exposed by properties such as elemObject.clientLeftand elemObject.clientTop) with styleobject positioning properties. The offset-related properties of non-positioned elements report widely different values in the two OS browser versions, especially if the non-positioned element is a component of a TABLE element. For example, attempting to position a floating element atop a TD element that is nested inside a TABLE will be difficult to accomplish across browsers without a great deal of browser-specific hand tweaking of values.

Reading mouse event coordinates in an element requires slightly different treatment in Mac and Windows versions of IE, especially if there is a chance that the page containing the element can be scrolled. At issue here is determining the coordinates of the event within the element. The event.offsetXand event.offsetYproperties in IE/Windows accurately report the offsets within the element. IE/Mac does, too, provided the page holding the element hasn't scrolled. If the page has scrolled, however, then the scrolling values (as determined by the document.body.scrollTopand document.body.scrollLeftproperties) are automatically subtracted from the event coordinates before they are reported. Thus, for the Mac version, you must add back the document.bodyscroll values to the event coordinates:

var leftInsideElem = event.offsetX + document.body.scrollLeft
var topInsideElem = event.offsetY + document.body.scrollTop

The Mouse Offset Lab page provides a living laboratory in which to experiment with the different event offset behaviors in IE4 or later on both operating systems. The page is wired so that anywhere you click the mouse pointer, the event offset values are displayed, as well as the tag of the element receiving the event (event.srcElement). Two sets of coordinates appear in the table. One set displays the values returned from the event.offsetXand event.offsetYproperties. In IE/Windows, if you scroll the page, the values returned by these eventobject properties report the correct values. In IE/Mac, however, the "raw" values are effected by the scrolling of the window (note the live scroll counter in the statusbar). To arrive at the desired values for the Mac, the scroll values must be added back to the offsets (see boldface lines of code the offset lab).

Playing with this lab page in both browsers reveals numerous subtle, but nonetheless important, differences in the way each OS version renders elements and treats transparent padding around some elements (where offset event coordinates can be negative values in both OS versions). For example, if you click in the centers of the checkboxes in both browsers, you see that the sizes are slightly different. Notice, too, how in IE/Mac, you cannot convey a click event to the very left and top edges of the BODY element.

Unimplemented Properties and Methods

In addition to the Windows-only features outlined earlier, a handful of Microsoft DOM properties and methods that are implemented in IE5/Windows (and some newer ones implemented in IE5.5/Windows) are not supported in IE5/Mac. If you have been developing pages for sites that must also accommodate IE4, then you are probably not using any of these IE5-only properties and methods. But if you have been limiting access to IE5 or later browsers, then see the table below for a list of the more popular properties and methods that you might be using but are not available in IE5/Mac.

Unsupported Properties and Methods in IE5/Mac

Object Type



HTML Elements canHaveChildren attachEvent()
  runtimeStyle componentFromPoint()
  uniqueID detachEvent()
document   recalc()
FORM   autocomplete
TABLE   moveRow()

You can see a consolidated view of event and other DOM item compatibility by downloading and printing an Adobe Acrobat version of a JavaScript and DOM Quick Reference.

"LiveConnect" Capabilities

The concept of having browser scripts communicate with plug-ins and Java applets started with Netscape 3 under the LiveConnect trademark. That term has become almost generic for this kind of communication, regardless of browser. IE5/Windows supports script access to Java applets and (more importantly to Microsoft) ActiveX controls. Unfortunately, that feature did not get into IE5/Mac. This is a big disappointment for many developers who have built pages around the power to control media players, such as recent versions of QuickTime and the Windows Media Player.

Speaking of plug-ins, you should be aware that IE/Mac manages plug-ins much the same way as Netscape Navigator. In other words, there is a one-to-one relationship between any given MIME type and a plug-in installed in the browser. Therefore, if you embed an audio element in your page, the browser will use whichever plug-in is currently enabled for the MIME type of the audio file that comes from the server. This differs from the IE5/Windows (and W3C DOM) approach, whereby an OBJECT element invokes a specific plug-in to play the file (assuming the desired plug-in is installed). One benefit of using the Netscape approach, however, is that IE5/Mac supports the same plug-in detection technique as Navigator, complete with navigator.pluginsand navigator.mimeTypesarrays whose objects report the same property values as Netscape Navigator. For many scripters, this kind of plug-in detection is much easier than the roundabout way scripts have to validate IE/Windows media player facilities -- the latter sometimes requiring a few lines of Windows-only Visual Basic Script (VBScript) to complete the job. For more on plug-in detection, give this article a read.

Testing on a Macintosh

While a Macintosh can emulate Windows (with the help of products such as Connectix's Virtual PC), as yet no Mac emulator exists for Windows. Therefore, to test your pages in IE/Mac, you'll need a Macintosh to do the job.

Related Reading

JavaScript: The Definitive Guide, 4th EditionJavaScript: The Definitive Guide, 4th Edition
By David Flanagan
Table of Contents
Sample Chapter
Full Description

It may be tempting to pick up a used Mac to be your testbench. If you do so, be sure it has the minimum requirements to run IE5: a PowerPC CPU and MacOS 7.6.1 or later. You will also save yourself a ton of development time if you can have the test Mac on a local area network with your development PC. Third-party products let Wintel and Macintosh computers share files and directories across an Ethernet or LocalTalk network. This setup allows you to edit only one source code file (or set of related files) in your favorite OS and test the results quickly -- ideally with a Wintel and Macintosh computer side by side. Include the Macintosh in your testing matrix as early in the development cycle as possible, especially if your scripting touches on any of the technical areas discussed earlier.

It's Worth the Effort

When developing public Web sites these days, it's potentially hazardous to do so within the confines of a single browser and operating system platform, regardless of what the installed base numbers tell you. Unless your site supports products aimed at a very narrow audience, you risk alienating a sizable number of potential visitors by demanding that everyone run your browser and your OS (this warning applies to Mac-centric developers, too). The more your site relies on proprietary browser features, the less friendly your organization may appear to lots of potential allies.

With today's browsers, even the lowest common denominator of JavaScript and DOM functionality allows pretty fancy user interface elements and "intelligent" pages. Sure, like any browser, Internet Explorer 5 for Macintosh has its scripting quirks, but it's no slouch when it comes to supporting the Microsoft and W3C DOMs with respect to HTML element objects and style sheets. Millions of active Mac users run it every day. When they come to your site, welcome them with open arms and well-behaved pages.

Danny Goodman has been writing about technology and computers full-time since 1981 and is the author of Dynamic HTML: The Definitive Reference and "The Complete HyperCard Handbook."

Return to the JavaScript and CSS DevCenter.

Copyright © 2017 O'Reilly Media, Inc.