Of course, even when a browser client 'supports' a method or property,
it does not always follow that it acts the same as
another browser. For instance, Opera claims to understand getAttribute and
setAttribute, but is severely limited in what can actually be
affected by using these methods.
Event handling is still the worst source for client script incompatability- Netscape and Sea Monkey support some event listeners, while IE5+ still rely on a window.event. So event handling has to be branched to each client. Screen display and page geometry still require proprietary scripting- innerWidth vs. clientWidth, pageX vs. offSetX- or is it parent.offSet?
CSS inheritance and support are also not uniform between browsers, but the differences are shrinking.
The next section will go into some browser specific reactions to document object methods and properties.
IE5 doesn't get any closer to the root of the document than the body, and it cannot create or manipulate a documentFragment at all. (IE6 has added support for documentFragment and the document root.)
All versions of IE before 6 insist that the cursor style associated with a link is called 'hand', while Netscape and Opera use 'pointer'. No big deal until you try to script an element's cursor. Without a switch for each browser you'll get invalid property errors.
Opera 5 is somewhere between the old browsers and the DOM enabled versions. It will render a nice looking page out of css and html, and it is fast, but it falters when you move from static to dynamic and interactive content.
You can use the DOM document.getElementsById(id) and the (element).style properties in Opera, but it does not yet extend to creating new elements and content. Though you can set the display property of any element when you load a document in Opera or Navigator 4, you cannot change it later. That one hurts...And Navigator will let you set the style of an element through it's id, using document.layer[layername].ids, (with the s), but only as the document loads.
Netscape 6/Mozilla supports the button element- at last. Unfortunately, Opera 5 still does not, and Navigator probably never will. You can use an iframe for importing content in Opera5, Netscape 6 and Sea Monkey, but so far IE5+ is the only one that gives you any significant presentation control of an iframe. You can now change the disabled attribute for form elements, but you don't get any visual clues when it happens in Opera or Netscape, unless you script them in.
Event handling in all the browsers is still finicky. I continue to be surprised if something actually works as specified. You shouldn't owe the pilot a standing ovation when he makes a routine landing.
IE5+ likes to wait until it has calculated the layout of the rest of the universe before it will update a display. I can't seem to make it incrementally display new content unless I break it up into smaller chunks.
You must have version 6 of IE to use the wild card in getElementsByTagName('*')
There are more specific behaviors- No two browsers handle css inheritance in exactly the same way, especially regarding font size and margin values.
And IE and Netscape don't always agree on whether an object is a child node or a sibling.
The biggest problem with IE5+ is in not using things that aren't supported by the other guys. I refer to IE's plethora of unique, powerful features, from filters to active x and databinding. An IE-only world gives you a lot of ready made tools, in the same way Visual Basic gives you a ton of prefab code. Of course, there is a price. The vast and awful sameness of of thousands of programs and millions of webpages attests to the actual limits of using menus to build applications.
Even when IE is on target with the recommendations, it is often a bit ahead of the pack.
When you traverse a document, Netscape and Sea Monkey put an element's attribute and text nodes on the same level- you will need some gymnastic ability to loop through an element's children and siblings in both clients. It doesn't hurt anything in IE to test the nodetype, but it does make more code...
And even though swapNode does exactly what you'd think in IE, to do the same thing in Netscape you have to mess about with cloning both nodes and replacing each original node with the clone of the other- a process somewhat less elegant than a Florida election.
If you have been writing code for browsers for a while you've been working on constantly shifting ground. The newest versions are closer to a single standard, but they still have surprises.
I used to spend a lot of bytes of code to equally support Internet Explorer and Netscape Navigator- I became proficient in all of Netscape's Layer methods, and the riches of active Microsoft. It is still possible to write such vendor based code, but life is short, and bandwidth is, mostly, narrow.
My strategy now is to write simple html, for the dumbest client, and then add, transparently, features for them that support the w3's recommendations. This will allow anyone to ge something from a web page, but only the new and improved clients will get the whole thing. I do hope the tendency continues to support the w3 recommendations. The document object model is such an advantage over any thing else.
There is an elegance in using methods like createElement. You are not simply typing a set of static instructions for the client application to parrot back. You are negotiating, interacting with the client, in a kind of creative partnership. It makes pounding out replacement content with document.write or innerHTML look like domestic violence. Wham. Bam.
The browser base is getting more homogenous- IE6 adds two more supported features, and does not seem to break any existing code. Mozilla/Netscape is even closer to full standard support. Event handling and css inheritance are still the biggest problem areas for webpage code writers. Probably by the time the vendors get it right we will be using xml for eveything- but that's another story...
When you can't trust a browser...
