oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Scripting for IE 5 Macintosh Edition
Pages: 1, 2, 3

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.