Java Server Pages, Java Programming - Cheap Web Hosting Blog

158Part IIIDocument Objects ReferenceA plus sign after a browser version number means that the language feature was first imple- mented in the numbered version and continues to be supported in succeeding versions. Aminus sign means that the feature is not supported in that browser. The browsers tested forcompatibility include Internet Explorer for Windows and Macintosh, Netscape Navigator, Mozilla (including all browsers based on the Mozilla engine), and Apple s Safari. I also recom- mend that you print the JavaScript and Browser Objects Quick Reference file shown inAppendix A. The file is on the companion CD-ROM in Adobe Acrobat format. This quick refer- ence clearly shows each object s properties, methods, and event handlers, along with keys tothe browser version in which each language item is supported. You should find the printoutto be valuable as a day-to-day resource. Language Essentials for Experienced ProgrammersIn this section, experienced programmers can read the highlights about the core JavaScriptlanguage in terms that may not make complete sense to those with limited or no scriptingexperience. This section is especially for you if you found the tutorial of Part II rudimentary. Here, then, is the quick tour of the essential issues surrounding the core JavaScript language: .JavaScript is a scripting language.The language is intended for use in an existing hostenvironment(for example, a Web browser) that exposes objects whose properties andbehaviors are controllable via statements written in the language. Scripts executewithin the context of the host environment. The host environment controls what, if any, external environmental objects may be addressed by language statements running inthe host environment. For security and privacy reasons, Web browsers generally affordlittle or no direct access via JavaScript to browser preferences, the operating system, or other programs beyond the scope of the browser. The exception to this rule is thatmodern browsers allow deeper client access (with the user s permission) through trustmechanisms such as signed scripts (Netscape) or trusted ActiveX controls (Microsoft). .JavaScript is object-based.Although JavaScript exhibits many syntactic parallels withthe Java language, JavaScript is not as pervasively object-oriented as Java. The core lan- guage includes several built-in static objects from which working objects are generated. Objects are created via a call to a constructor function for any of the built-in objects plusthe newoperator. For example, the following expression generates a Stringobject andreturns a reference to that object: new String( Hello ); Table 13-1 lists the built-in objects with which scripters come in contact. Table 13-1: JavaScript Built-In ObjectsArray1BooleanDateError2EvalError2Function1MathNumber1Object1RangeError2ReferenceError2RegExp3String1SyntaxError2TypeErro2URIError21Although defined in ECMA Level 1, was first available in NN3 and IE3/J2.2Defined in ECMA Level 3; implemented in Moz1.3Defined in ECMA Level 3; implemented fully in NN4 and IE6.

157Chapter 13JavaScript EssentialsFigure 13-1:The Evaluator Sr. First, you can try some Netscape/Mozilla secure features if you have Code Base Principlesturned on for your browser (Chapter 46 on the CD-ROM) and you check the Use Code BaseSecurity checkbox (NN4+ only). Second, the page has several HTML elements preinstalled, which you can use to explore DOM properties and methods. As with the smaller version, a setof 26 one-letter global variables (athrough z) are initialized and ready for you to assign val- ues for extended evaluation sequences. You should copy the file evaluator.htmlfrom the companion CD-ROM to a local hard diskand set a bookmark for it in all of your test browsers. Feel free to add your own elements tothe bottom of the page to explore other objects. I describe a version of The Evaluator forembedding in your projects as a debugging tool in Chapter 45 on the CD-ROM, where you canlearn more built-in functionality of The Evaluator. Compatibility ratings in reference chaptersWith the proliferation of scriptable browser versions since Navigator 2, it is important toknow up front whether a particular language or object model object, property, method, orevent handler is supported in the lowest common denominator for which you are designing. Therefore, beginning with Chapter 15 of this reference part of the book, I include frequentcompatibility ratings, such as the following example: Compatibility: WinIE5+, MacIE5+, NN4+, Moz1.01+, Safari1+

156Part IIIDocument Objects ReferenceDealing with beta browsersIf you have crafted a skillfully scripted Web page or site, you may be concerned when a pre- release (or beta) version of a browser available to the public causes script errors or othercompatibility problems to appear on your page. Do yourself a favor don t overreact tobugs and errors that occur in prerelease browser versions. If your code is well written, itshould work with any new generation of browser. If the code doesn t work correctly, con- sider the browser to be buggy. Report the bug (preferably with a simplified test case scriptsample) to the browser maker. The exception to the it s a beta bug rule arose in the transition from NN4 to the new Mozillaengine (first released as NN6). As you learn in Chapter 14, a conscious effort to eliminate aproprietary NN4 feature (the tag and corresponding scriptable object) caused manyNN4 scripts to break on Moz1 betas (and final release). Had scripters gone to report the prob- lem to the new browsers developer (Mozilla), they would have learned of the policy change, and planned for the new implementation. It is extremely rare for a browser to eliminate a pop- ular feature so quickly, but it can happen. It is often difficult to prevent yourself from getting caught up in browser makers enthusiasmfor a new release. But remember that a prerelease version is not a shipping version. Userswho visit your page with prerelease browsers should know that there may be bugs in thebrowser. That your code does not work with a prerelease version is not a sin, nor is it worthlosing sleep over. Just be sure to connect with the browser s maker either to find out if theproblem will continue in the final release or to report the bug so the problem doesn t make itinto the release version. The Evaluator Sr. In Chapter 6, you were introduced to a slimmed-down version of The Evaluator Jr., which pro- vides an interactive workbench to experiment with expression evaluation and object inspec- tion. At this point, you should meet The Evaluator Sr., a tool you will use in many succeedingchapters to help you learn both core JavaScript and DOM terminology. Figure 13-1 shows the top part of the page. Two important features differentiate this full ver- sion from the Jr. version in Chapter 6. IE Browser Version HeadachesAs described more fully in the discussion of the navigatorobject in Chapter 38 on theCD-ROM, your scripts can easily determine which browser is the one running the script. However, the properties that reveal the version don t always tell the whole story about Internet Explorer. As you can see in detail in Chapter 38 on the CD-ROM, the navigator.appVersionproperty forIE5, 5.5, and 6 for Windows reports version 4 (the same as IE4). You can still sniff for versions5 and 6 (you can find the designation MSIE 5or MSIE6in the navigator.userAgentproperty), but the process is not as straightforward as it could be. The best advice is to be vigilant whennew browsers come on the scene or adopt object detection techniques in your scripts.

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.