155Chapter 13JavaScript EssentialsIf the test for (Web hosting support) document.bodyfails, JavaScript
155Chapter 13JavaScript EssentialsIf the test for document.bodyfails, JavaScript bypasses the second test. One potential gotcha to using conditional expressions to test for the existence of an object sproperty is that even if the property exists but its value is zero or an empty string, the condi- tional test reports that the property does not exist. To work around this potential problem, theconditional expression can examine the data type of the value to ensure that the property gen- uinely exists. A nonexistent property for an object reports a data type of undefined. Use thetypeofoperator (see Chapter 32) to test for a valid property: if (document.body && typeof document.body.scroll != undefined ) { // statements that work on the body s scroll property} Object detection is the wave of the future, and I wholeheartedly recommend designing yourscripts to take advantage of it in lieu of branching on particular browser name strings andversion numbers. Scriptable features are gradually finding their way into browsers embeddedin a wide range of non-traditional computing devices. These browsers may not go by thesame names and numbering systems that we know today, yet such browsers may be able tointerpret your scripts. By testing for browser functionality, your scripts will likely require lessmaintenance in the future. You can see more object detection at work in Chapters 47 and 56on the CD-ROM. Designing for CompatibilityEach new major release of a browser brings compatibility problems for page authors. It s notso much that old scripts break in the new versions (well-written scripts rarely break in newversions with the rare exception of the jump from NN4 to the new browser engine in Mozilla). No, the problems center on the new features that attract designers when the designers forgetto accommodate visitors who have not yet advanced to the latest and greatest browser ver- sion or who don t share your browser brand preference. Catering only to the lowest common denominator can more than double your developmenttime due to the expanded testing matrix necessary to ensure a good working page in all operat- ing systems and on all versions. Decide how important the scripted functionality you employ ina page is for every user. If you want some functionality that works only in a later browser, youmay have to be a bit autocratic in defining the minimum browser for scripted access to yourpage any lesser browser gets shunted to a simpler presentation of your site s data. Another possibility is to make a portion of the site accessible to most, if not all, browsers, andrestrict the scripting to only the occasional enhancement that nonscriptable browser userswon t miss. Once the application reaches a certain point in the navigation flow, the user needs amore capable browser to get to the really good stuff. This kind of design is a carefully plannedstrategy that lets the site welcome all users up to a point, but then enables the application toshine for users of, say, W3C DOM-compatible browsers. The ideal page is one that displays useful content on any browser, but whose scripting enhancesthe experience of the page visitor perhaps by offering more efficient site navigation or interac- tivity with the page s content. That is certainly a worthy goal to aspire to. But even if you canachieve this ideal on only some pages, you will reduce the need for defining entirely separate, difficult-to-maintain paths for browsers of varying capabilities. Regardless of your specific browser compatibility strategy, the good news is that time tends tominimize the problem. Web standards have solidified greatly in the past few years, and browservendors are finally making a more serious effort to support those standards. Furthermore, as more of the Web community upgrades to modern browsers, the issue of supporting oldbrowsers becomes less and less significant. Bottom line there is light at the end of the tunnel.