The DOM and Compliant Browsers

The DOM and Compliant Browsers

There is no such thing as complete cross-browser compatibility. I doubt there ever will be, even though the differences between browsers become smaller every year. The W3C DOM is responsible for much of this compatibility, and most browsers have implemented support for both the Core and HTML APIs. This includes Mozilla/Firefox, Netscape Navigator (6.0 and above), Internet Explorer (6.0 and above), Safari, Opera (7.0 and above), Camino, and others.

However, not all aspects of the DOM are implemented equally among all the browsers; as discussed in Chapter 6, Internet Explorer (neither 6.x nor 7+) does not support the DOM Level 2 event model. There are also individual differences in support for CSS, as well as object methods and properties that differ between the browsers.

Most of the compliance issues are subtle, with minor variations in support. They are enough, however, to require testing of any effect using the DOM APIs to ensure it looks good or works as expected with all of your target browsers.

As to the variations, one variation could be providing too much support, such as Firefox providing DOM-level access to the name attribute on all HTML elements, not just those for which it's valid. This is just as much an error, or lack of compliance, as no support for the event modelparticularly if you develop in Firefox and build in an expectation for name to be JavaScript-accessible on all elements.

Another variation is more of a minor annoyance than anything. There are a set of constants built into the DOM so that you don't have to code in numeric references for something such as nodeType, which provides information about the type of DOM node you're working with when you access the page document as a whole. However, as shown later in the section discussing the Core model, and thanks to JavaScript's prototype nature (covered in the next chapter), you can work around this limitation by adding these constants where they don't exist.

Regardless of all the browser quirks, there are few noncompliance issues that can't be worked around. The only decisions that remain are how much time you want to spend on such effort, and how many browsers, browser versions, and operating systems you want to support. One key element of this is reviewing your web logfiles to see how your pages are accessed. Many ISPs provide access to your raw logfiles in some form or another, and each consists of lines that might look similar to the following (from one of my site's logfiles): - - [30/May/2006:07:24:18 -0400] "GET / HTTP/1.1" 200 67510 "" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20060426 Firefox/"

From left to right, the first field is usually the IP address of the person (or web bot) accessing the page; the fields represented by the dashes are the identity lookup and authenticated usernames that are found (if any); then follows the date, the page requested, the referrer, and finally information at the end that represents the operating system and user agent. With this example, the OS is Mac OS X, the language is English, and the user agent is Firefox 1.5.03. The order of fields may vary, but the user agents and operating system are usually fairly obvious:

"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7"
"Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/418 (KHTML, like Gecko) Safari/417.9.2"
"Opera/9.00 (Windows NT 5.1; U; en)"

Note that browsers may claim to be Mozilla 5.0; the actual browser is a secondary piece of information.

As long as your pages degrade gracefully (i.e., don't force a certain type of browser on your web-page readers and ensure that it still works for nonsupported types), you don't have to support all browsers or browser versions for your DOM-specific effects.

JavaScript Best Practice: Ensure your pages degrade gracefully when accessed by all browsers, including ones that don't have JavaScript enabled or that don't support specific DOM functionality.

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows