|
|
JavaScript |
Back to the index page/no-frames HTML
In this reference, we have taken a snapshot of current web browser JavaScript implementations, which need to be supported by web sites, and collated that information together in a form that has broad scope and is deep enough to be useful on a day-to-day basis. As the language is growing all the time, this is likely to be an ongoing task.
There are now in excess of 3500 individual topics in this work. That is more than twice as many as we have room for in the book so we have put a useful subset of the reference into the printed book. Here though you're looking at the complete reference.
We've split the introduction into the following sections:
The book is aimed at people who already have some knowledge of JavaScript and need a companion volume to their daily work. It is primarily aimed at the experienced practitioner, and so does not attempt to be a tutorial for the beginner.
Typical uses of the book include times when you:
One important motivation I had for writing this book was to reduce the amount of material I have to carry around when I'm working on projects in my clients' offices. I set out to try and distil enough useful information into one book and organize it so that the information is easy to find. I've also put in material on issues that I've encountered in discussions with other programmers.
For a tutorial book, we suggest Paul Wilton's Beginning JavaScript (Wrox Press, 2001, ISBN 1-861004-06-0).
There is still much that is ambiguous or not yet defined in the standards and the browser manufacturers continue to add new features in competition with one another. Even though they are standards compliant at a functional level, there are still significant differences if you 'look under the hood'.
We have included coverage of the following standards:
JavaScript implementations we cover include:
By implication that means we cover JavaScript versions up to 1.5 and JScript up to 5.5. The coverage of Netscape 6.0 is based on it supporting the W3C DOM standards and several bugs in the currently released version prevented the verification of some functionality although that may be platform dependent. There are also some new and unexpected features.
We concentrate our discussions on the peculiarities of Netscape and MSIE because the other browsers that support JavaScript attempt to provide a fault-free standards-based implementation.
For some time, the most popular browsers have been Netscape Navigator 4.7 and Microsoft Internet Explorer 5.0 (MSIE).
The dominant browsers have long competed with one another to add new features. Architecturally, this means their browsers have each gone in a completely different direction. The penalty has been that support for various language features has been implemented in each browser in ways that makes it difficult to use in a portable way. Indeed, to make use of some features requires twice the work, since the same code has to be written in two different ways and called after detecting which browser is being used.
Because of the proliferation of browser versions and platforms, features are generally referred to as being available in the revision in which they were first introduced. As the Netscape browser is available on so many different platforms, to test for compliance across all platforms would require a test suite of a dozen machines and 30 or more different installations of browser applications. Indeed, when building such a test suite just prior to starting on this book, I found more than a dozen distinctly different browser versions just for the Macintosh platform and many more than that for Windows. Similarly, MSIE comes in a bewildering variety of versions and platform variants. In addition, the JScript interpreter is a replaceable component that can be upgraded without changing the containing browser.
There are now a wide variety of sources of information about JavaScript and they don't all agree. In particular there is some uncertainty over which release of JavaScript introduces certain features.
The source material was assimilated by examining the standards documents and by inspecting objects with fragments of JavaScript. Then, the availability of features was checked against several alternative reference works. Occasionally, when a consistency error showed up, it was necessary to go back to the browser and test for the availability of a property or method.
Where there is some room for doubt, we have documented the release at which the feature became useful. This is because in earlier releases it may have had a serious flaw or been significantly revised later to make it work properly. Any implementation prior to that may be unreliable. So where we may appear to disagree with other commentators our coverage is based on whether it is practical to use a particular feature at a certain release.
Some browser features are available at an earlier release on some platforms than others are. We take the Windows 32-bit release as our baseline although significant testing was also done on the Macintosh versions, which disappointingly lagged somewhat in performance and feature availability. Both platforms exhibited instabilities and crash-prone behavior but in quite different areas of the language.
As there are so many variants of the browsers, the availability matrix for objects and their member properties/methods is huge and requires a large amount of work to test on all the available combinations. So far, no single reference source has proven to be error free and whilst the information here has been examined and cross-checked it is still likely that there are errors. If, in your work, you disagree with the information provided here, please send feedback (see the end of the Introduction for how to do this).
At first glance, the JavaScript environment appears to be built around a small core of objects and it is easy to fall into the trap of assuming the language is small and compact. That is certainly true if you are only considering core JavaScript functionality. The core language is defined by ECMA and both Netscape and MSIE claim to be ECMA compliant. They may well be, but you cannot write much useful JavaScript for deployment in a web page by confining yourself only to the functionality of the ECMA standard. It is at that point that the two browsers begin to diverge.
Likewise, both browsers (MSIE 5 upwards and Netscape 6) claim to be DOM compliant. Browser support for the DOM is slowly converging but if you need to do any esoteric code development that involves DOM traversal and class names, they are still somewhat different.
MSIE implements a DOM model that is structurally right, but the class names of the objects that comprise that model are certainly not correct and do not conform to the DOM standard. Netscape 6 implements a DOM compliant model that does use the correct class names. Another slight difference is that MSIE implements distinctly different classes for some objects whereas Netscape Navigator instantiates the same class for several purposes.
These differences don't cause much grief to you when you are constructing simple scripts and web page enhancements but can be quite a problem if you need to manipulate the DOM structure and operate on objects by means of their class names. This difference did not become apparent until I used inspection scripts to examine internal document structures.
There are also areas where DOM specifies objects in a way that the browsers can implement ambiguously. For example, DOM describes documents as being a generic document class with an HTML document as a sub-class. Browsers simply provide a single document class with no access to the two separate class types.
You might also assume that there is a small and finite set of different object types. However if you inspect the constructor properties and examine the function names, you will find the opposite, there are a large number of object types. For example, the applets property that returns a list of applets in a document will give you an AppletArray object and not a Collection object in Netscape. Trying to work out class names on MSIE is a bit more problematic and it tends to provide generic Collection objects instead. By building fragments of JavaScript to inspect objects, you can determine these class names and learn a lot about how the browser maintains the internal model of the page.
The topics are constructed around a browser-centric model. The objects are defined based on their instantiation by an HTML tag in a web browser window. MSIE creates a distinct object class for each tag. Netscape does a similar trick, but not so convincingly in earlier versions. At version 6, the objects are DOM compliant and named differently to those in MSIE and earlier Netscape browsers. Netcsape 6 is so different as to be a new browser with little similarity to the earlier versions of Netscape.
There is an emerging standards-based model that frames the object hierarchy much more logically and, while it is still evolving, it may become a more robust way of describing the catalog of available classes. For now, though, the web and browser dominate use of JavaScript, so this seems like the more appropriate model.
Another area of debate is the document object. Typically, the previous documentation describes access to it as if there is only one document object. This is true within the context of a single script within a page. However, it is not necessarily true of a window in a web browser. A window may contain many frames or layers. Each one will have its own private document object. If you are writing scripts that operate across multiple frames or windows, you may refer to several document objects, so the syntax examples are designed to accommodate the different ways in which objects can be accessed.
To make it easy to navigate through the topics, titles describe the topic content and the topic type and are organized alphabetically.
Where we discuss an object all the important properties, methods, events, and any supporting material are broken out into their own topics. Where objects inherit properties and methods, they are listed in the object coverage but to avoid duplication the information about the inherited properties is described as a member of the super-class. This slightly detracts from the lexical referencing but it saves space. In some cases these inherited properties/methods are deemed important enough to merit a cross-referencing entry of their own.
This allows us to indicate availability of features at a very fine level of detail. Within each topic we can also discuss bugs, gotchas, and areas of difficulty in a focused way.
Entries for objects summarize the support for important methods and properties. The Notes column in those tables notes any deprecations and other warnings, details of which can be found in that method or property's topic.
Language syntax is illustrated by way of example code fragments that show how to access an object, method, or property. More extensive examples are given where necessary.
Because of the scoping rules, properties are available without the need for the window object to be specified as a prefix. Thus navigator as a topic is available under the window.navigator topic as well. Once you have found an entry topic, you can then use the cross-referencing listings to locate other related material.
The book content was developed inside a database system, which provided tools to relate topics. The benefit is a rich source of cross-referencing links between topics. The cross-reference in the printed book is complete; that is, it also includes entries found only on the CD.
The topic listing in the top-left frame allows you to browse entries by their type. In particular, collections, events, methods, and properties are listed alphabetically, showing all the references to them, and the objects to which those references belong.
To make navigation easier, the e-book contains an interactive table of contents, thumbnails, and hyperlinks in the entries.
All of the code examples given in the book are available on the CD, and are also available to download from our web site, www.wrox.com.
The convention used for syntax naming is that a variable created within the local scope would be prefixed with my while a global variable would be prefixed with the. Parameters passed into function and method calls are prefixed with a, an, or some.
The syntax description for an object shows how a reference to an object of that class can be retrieved via a property or method on another object. The syntax for properties and methods show them as members of an object that is referred to with a variable. This manifests itself as an object reference like this:
myDocument = document myDocument = myElement.parentNode myDocument = myFrame.document myDocument = myLayer.document
Then a property reference looks like this,
myDocument.cookie
and not:
document.cookie
Of course you can omit the indirection through a referencing variable and any of these would be equally valid:
document.cookie myElement.parentNode.cookie myFrame.document.cookie myLayer.document.cookie
But by using the indirection, the syntax descriptions for the member properties and methods are simplified.
In the tables, we have used the abbreviations N for Netscape, NES for Netscape Enterprise Server, and IE for Internet Explorer.
Wrox has three ways to support books. You can:
If you wish to point out an errata to put up on the website or directly query a problem in the book with an expert who knows the book in detail, then e-mail support@wrox.com.
You may want to tell us your opinion of this book, or you may have ideas about how it can be improved, in which case, e-mail feedback@wrox.com. We will do our utmost to act upon your comments.