Writing Friendly Code-Part 2,Browsers
The Clockwise Box (Dueling Browsers)
Nearly every element that is called from a script can have its own container. Write to the container, and the content will usually go along for the ride. Some things that seem to be separate, accessible objects on their own - like links, images, tables and forms - do not behave alike in different browsers. IE 4 and 5 let you attach an id to almost any element, and you can do pretty much what you like to it from a script by calling its document.all[id].style object.
It sometimes seems you are doing a lot of work to accommodate Netscape's version 4 browsers. Navigator 4 doesn't let you write changes to any properties (except an image src or bgColor) unless you are manipulating a layer. When writing friendly, you define these layers as the officially recommended <div> or <span> tags with the position attribute set to "absolute" or "relative". Navigator reads any positioned containers as layers. You can access all the Netscape layer methods and properties as if the layer tag was present.
When you make an element's position absolute, you remove it from the normal flow of the page, and once you do that you must then account for it. This means you have to define where on the page it is to be located, and also where on the page the rest of the content is located. This involves specifying the top and left properties of the containers, or you will find your elements rendering on top of each other. You can use this effect if you want a "layered" look to your page, or if you use the visibility property to selectively show or hide the different content areas in turn. It is an easy place to mess up, however. I always set the top and left properties of absolute positioned elements in the style sheet, even if they are all set at 0.
In other words, if you absolute position anything, you should position everything.
It's not just Navigator that needs its hand held and nose wiped. While I was writing this article, I applied a style to an ordered list that worked without a hitch in Navigator, but if I tried the same thing in IE, I got all kinds of weird results. Navigator displayed it as one would expect, as a numbered list, but IE showed a bulleted list. I tried giving the ol element tag the css attribute "list-style-type:decimal", supposedly the default. Navigator continued to work properly but IE now put the number 1 in front of each item. I gave each li element in the list the style-type attribute, and they still all showed number 1. Finally I wrapped the whole list in a div container and applied the style to the div, and IE wised up and acted like that was what I should have done to start with. Through all of these contortions, Navigator behaved like a pro.
The snazziest features in IE not only aren't recognized by Navigator, they only work on a Windows environment. A lot of them aren't in any W3C proposal, either. Many of them won't ever be. Things that are easy to get used to, like the innerHTML and insertAdjacentText and textRanges and databinding and transitions - these are not likely to be in any new standard.
The proposals for the next DOM implement methods like createHtmlElement, and a host of document oriented methods and properties that neither of our favorite vendors has managed yet. Next time you start getting cocky about the latest browser from Microsoft, trot it on over to the DOM test suite and see how you fare. IE does better than Navigator on the DOM 1 test, but it doesn't get any bragging points. And giving either browser a taste of DOM 2 is like giving Superman a kryptonite sandwich. In this next DOM, for instance, event handlers will both "listen" and "bubble", which is like grafting a branch from Netscape and another from Microsoft onto the same tree. We'll see - but meanwhile, we have Web pages to build.
Comments are welcome