We've covered a lot in this chapter, but now we have all the grounding we need to move on to more useful things, such as forms and user input, and later on to more advanced areas of text and date manipulation.
The first of the main objects we looked at was the window object. This sits at the very top of the BOM's hierarchy. The window object contains a number of important sub-objects, including the location object, the navigator object, the history object, the screen object, and the document object.
The location object contains information about the current page's location, such as its file name, the server hosting the page, and the protocol used. Each of these is a property of the location object. Some properties are read-only, but others, such as the href property, not only allow us to find the location of the page, but also can be changed so that we can navigate the page to a new location.
The history object is a record of all the pages the user has visited since opening his or her browser. Sometimes pages are not noted (for example, when the location object's replace() method is used for navigation). We can move the browser forward and backward in the history stack and discover what pages the user has visited.
The navigator object represents the browser itself and contains useful details of what type of browser, version, and operating system the user has. These details enable us to write pages dealing with various types of browsers, even where they may be incompatible.
The screen object contains information about the display capabilities of the user's computer.
The document object is one of the most important objects. It's an object representation of our page and contains all of the elements, also represented by objects, within that page. The differences between Netscape and Microsoft browsers are particularly prominent here. If we want cross-browser-compatible pages, we find we are quite limited as to which elements we can access.
The document object contains three properties that are actually arrays. These are the links, images, and forms arrays. Each contains all the objects created by the <A>, <img>, and <form> tags on the page, and it's our way of accessing those tags.
The images array contains an img object for each <img> element on the page. We found that even after the page has loaded, we can change the properties of images. For example, we can make the image change when clicked. The same principles for using the images array apply to the links array.
Connecting functions that we have written to event handlers is simply a matter of adding an attribute to the element corresponding to the particular object we are interested in. The attribute has the name of the event handler we want to capture and the value of the function we want to connect to it.
In some instances, such as for the document object, a second way of connecting event handlers to code is necessary. Setting the object's property, with the name of the event handler, to our function produces the same effect as if we did it using the event handler as an attribute.
In some instances, returning values from event functions allowed us to cancel the action associated with the event. For example, to stop a clicked link from navigating to a page, we returned false from the event handler's code.
Finally, we looked at how we can check what type of browser the user has so that we can make sure the user only sees pages or parts of a page that his browser is compatible with. The navigator object provides us with the details we need, in particular the appName and userAgent properties. We can also check specific BOM properties to see if they are supported before using them. If a browser doesn't support a specific property needed for our code to work, we can either write alternative code or let the user know he needs to upgrade his browser.
That's it for this chapter. In the next chapter we can move on to more exciting form scripting, where you can add various controls to your page to help you gather information from the user.