151Chapter 13JavaScript Essentialsscript-enabled browsers, as involved as setting (Web hosting compare)
151Chapter 13JavaScript Essentialsscript-enabled browsers, as involved as setting up distinct areas of your application for dif- ferent browser classes, or any degree in between. The first step in planning for compatibil- ity is determining what your goals are for various visitor classes. Establishing goalsOnce you map out your application, you must then look at the implementation details to seewhich browser is required for the most advanced aspect of the application. For example, ifthe design calls for image swapping on mouse rollovers, that feature requires NN3+ and IE4+, which is a relatively safe assumption these days. In implementing Dynamic HTML features, you have potentially three different ways to implement tricks (such as movable elements orchangeable content) because the document object models require different scripting (andsometimes HTML) for NN4, IE4+, and the W3C DOM implemented in Moz1+, IE5+, Safari, andother recent browsers. In an ideal scenario, you have an appreciation for the kinds of browsers that your visitorsuse. For example, if you want to implement some DHTML features, but NN4 usage is only asmall and decreasing percentage of hits, you can probably get by with designing for the IE4+ and W3C DOM. Or you may wish to forget the past and design your DHTML exclusively forW3C DOM-compatible browsers. If your Web hosting service maintains a log of visitor activityto your site, you can study the browsers listed among the hits to see which browsers yourvisitors use. After you determine the lowest common denominator for the optimum experience, you thenmust decide how gracefully you want to degrade the application for visitors whose browsersdo not meet the common denominator. For example, if you plan a page or site that requires aW3C DOM-compatible browser for all the bells and whistles, you can provide an escape pathwith content in a simple format that every browser from Lynx to IE4 and NN4 can view. Youmight even provide for users of handheld devices a third offering with limited or no script- ability that is designed specifically for a constrained user interface. Creating an application or site that has multiple paths for viewing the same content maysound good at the outset, but don t forget that maintenance chores lie ahead as the siteevolves. Will you have the time, budget, and inclination to keep all paths up to date? Despite whatever good intentions a designer of a new Web site may have, in my experiencethe likelihood that a site will be maintained properly diminishes rapidly with the complex- ity of the maintenance task. Implementing a branching index pageIf you decide to offer two or more paths into your application or content, one place you canstart visitors down their individual paths is at the default page for your site. Numerous tech- niques are available that can redirect visitors to the appropriate perceived starting point ofthe site. One design to avoid is placing the decision about the navigation path in the hands of the visi- tor. Offering buttons or links that describe the browser requirements may work for users whoare HTML and browser geeks, but average consumers surfing the Web these days likely don thave a clue about what level of HTML their browsers support or whether they are JavaScript- enabled. It is incumbent upon the index page designer to automate the navigation task asmuch as possible. A branching index pagehas almost no content. It is not the home page per se of the site, butrather a gateway to the entire Web site. Its job is to redirect users to what appears to be thehome page for the site. Listing 13-3 shows what such a branching index page looks like.