192Part IIIDocument Objects ReferenceUnfortunately, neither IE5 through IE6 (Web server setup)
192Part IIIDocument Objects ReferenceUnfortunately, neither IE5 through IE6 on Windows nor IE5 for Macintosh implements theW3C DOM event model. You can, however, make the two event models work together if youassign event handlers by way of object properties or tag attributes, and throw in a littleobject detection described later in this chapter and in more detail in Chapter 25. Mixing Object ModelsThe more browsers that your audience uses, the more likely you will want to make your pageswork on as many browsers as possible. You ve seen in this chapter that scripts written for olderbrowsers, such as Navigator 2 and Internet Explorer 3, tend to work in even the latest browserswithout modification. But aiming at that compatibility target doesn t let you take advantage ofmore advanced features, in particular Dynamic HTML. You must balance the effort required tosupport as many as four classifications of browsers (non-DHTML, NN4, IE4/5, and W3C DOMcommon denominator in IE6 and Moz1) against the requirements of your audience. Moreover, those requirements can easily change over time. For example, the share of the audience usingnon-DHTML and NN4 browsers will diminish over time, while the installed base of browserscapable of using the Microsoft IE DOM (for IE4+) and the W3C DOM (IE6+ and Moz1+) willincrease. If the percentage of visitors using NN4 is not significant at this point, you may welldecide to not worry about implementing DHTML features for that browser and lump NN4together with the rest of the non-DHTML browsers. For any given application or Web site, it is important to develop a strategy to apply to thedeployment of scripted features. But be aware that one strategy simply cannot fit all situa- tions. The primary considerations are the breadth of browser versions reaching your site(many for public sites; perhaps only one for a tightly controlled intranet) and the amount ofDHTML you intend to implement. In the rest of this section, you see three scenarios and strategies employed to meet the devel- oper s requirements. Although they are labeled as three different levels of aggressiveness, itis likely that you can apply individual techniques from each of the levels in establishing astrategy of your own. The conservative approachIn the first scenario, the content requires a modest level of data entry interaction with a uservia a form as well as image rollovers. Supported browsers encompass the entire range of non- scriptable and scriptable browsers, with one version of each page to serve all visitors. If the form gathers information from the user for submission to a server CGI that stores thedata in a database or performs a search based on user-supplied criteria, the obvious modeof entry is through traditional form control elements. Scriptable browsers can perform pre- submission validations to hasten the correction of any improperly formatted fields. Eventhandlers attached to the text fields (onchangeevent handlers) and an onsubmitevent han- dler for the form itself can do the validation on the client. Nonscriptable browsers ignore theevent handlers, and the form is submitted as usual, relying on server-side validation of inputdata (and the slow back-and-forth processing that this entails when there is an error or miss- ing field data). For image rollovers, links surround the image elements. The onmouseoverand onmouseoutevent handlers for the links trigger functions that swap images. By wrapping the statementsin the event handler functions in ifconstructions that test for the presence of the document.imagesarray, first-generation scriptable browsers that don t implement images as objectsperform no action: