Preparing for standard-compliant browsers, Part 2

In: Articles

By Makiko Itoh

Published on July 9, 2001

This is Part 2 of two articles written specifically with web designers rather than coders in mind, about preparing for World Wide Web Consortium (W3C) standards-compliant browsers such as Netscape 6 and Microsoft Internet Explorer 5 for the Macintosh.

Since Digital Web is a webzine for designers, I am assuming that most of you reading this article are not programmers. But so far, much of the writing about Netscape 6, the new Document Object Model (DOM), seems to have been written for and by programmers. Are you confused? If so, hopefully by the time you’ve reached the bottom of this page, you will be a little bit more clear about what’s in store for you as you prepare yourself to create your web page for the newer browsers and to take best advantage of the possibilities of cross-browser Dynamic HTML (DHTML).

In Part 1, I talked about the importance of cleaning up your HTML and CSS. Some of you might have found this redundant, but I did want to emphasize the importance of doing this, because this will help you to reduce untold numbers of headaches later on as you create DHTML pages.

In Part 2 we’ll discuss the base concept behind the view of a web page as a collection of objects which forms the foundation of all DHTML scripting; describe the different object models in the browsers and the all-important W3C DOM; talk about some real-life reality issues; then finally give a few short examples which show the DOM in practice.

A note: I use the terms element and box interchangeably here, but they mean the same thing. “Element” is an official term, while “Box” is a term I often use to try to explain the concept.

Changing your view of the structure of a web page Before you proceed with any kind of DHTML, ponder the following:

Stop thinking of tags for formatting. Think of them as boxes that contain changeable content. The box together with the content and attributes (or the styles) of the contents make up an element, which you can manipulate freely.

If you have been sticking mainly to HTML 3.2 and/or table-based page layouts, or you’ve come to the web design world from paper-based graphic design, this may be not so intuitive. You already know that a web page is not a static, fixed document like a paper document is, but you may still be thinking of the layout and design process in static terms. In other words, many web designers treat a web page like a jigsaw puzzle, where precisely predefined and pre-sized pieces must fit together exactly so.

In reality, up until recently, web pages have mostly been static. While the ubiquitous mouse rollover has brought a basic level of animation to many pages, because of the limitations and problems in implementation of DHTML in the browsers, most pages haven’t progressed much beyond that, and many web designers have been reluctant to add more and face debugging and cross-browser problems. Moreover, the so-called “second generation” theory of web page design popularized by influential authors such as David Siegel, made many designers treat a web page like a paper page using such tricks as tables, transparent “spacer” GIFs and so on. However, the advent of browsers that take advantage of the W3C DOM will change that, and hopefully in time widespread adaptation of a standard way of handling web page elements will make cross-browser checking and headaches a thing of the past.

In order for you as a designer to take full advantage of this, it’s necessary to make a fundamental shift in thinking. Instead of thinking of your pages like fit-together jigsaw puzzles, think in terms of the page as a collection of self-contained, malleable elements. Each element on the page can be manipulated by you, the designer, in more ways than you previously thought possible. It’s an exciting prospect indeed – if you know how to take advantage of it. To help you visualize this, take a look at the two illustrations below. The first illustration shows the traditional static view of a web page. The second , Dynamic HTML view, shows a view of the page as a selection of elements or boxes. Your task, should you choose to take it on, is to master this model.

The HTML tag reviewed
To review: the basic HTML tag that you’ve been using so far has these parts:

• Tag name
• Class Name
• ID

These are the elements you will probably still be using exclusively most of the time, but in addition to these you will also be able to use dir, lang, and title.

The most important thing to remember, as I reiterated in Part 1, is to always close your tags. Remember – your tags are “wrappers” for the boxes or elements that make up your document, and you don’t want your boxes to have no bottom so that things spill out and make a mess!

The second important thing is that each tagged element on your page can be identified as a unique entity. You should make yourself follow the habit of identifying each taggable element with a unique ID if you want to manipulate it.

These two principles apply not only to HTML, but will apply to XML and other new things coming up faster than you think on your horizon.

Now let’s go on to the knotty subject of the Document Object Model. (Veteran Netscape 4 and IE coders may wish to skip ahead to no. 3, the W3C DOM.)

The Document Object Model explained
From my dealings with designers who have no programming background, grasping the reasoning behind the Document Dbject Model of a web page is a stumbling block for many. Many know to refer to objects on a Netscape page with the “document.layers” method and to objects on an IE page with “document.all” but don’t know why they are doing it. However, understanding this concept is crucial for an understanding and mastering of Dynamic HTML.

In a nutshell, the document object model is basically a way of addressing the objects on the page. In order to manipulate the objects on the page, they must be addressed correctly. But to make life complicated, the main browsers which support some form of Dynamic HTML – Netscape 4x, MSIE 4 and 5x, and W3C-standard browsers, all have different addressing methods. For this article we’ll refer to them respectively as the Netscape (proprietary) model, the IE (proprietary) model and the W3C DOM or simply DOM.

1. First, let’s look at the basic Netscape model supported by Netscape version 4x:

document.objectName

For example, when you address a “form element” named “myForm”, you would address it like this:

document.myForm

You can address a limited set of styles in a limited number of objects in Netscape 4, and to reach these style elements you address them like this:

document.objectName.styleProperty

For example, you can address the “visibility style” property of an object named “myBox” like this:

document.myBox.visibility

“But what about this ‘document.layers’ thing that I’m always told I have to use with Netscape?” you might be asking. As already mentioned, Netcape 4x exposes only a select few elements on a page to manipulation. The most controllable one is the Netscape 4-proprietary element called LAYER – an independent block level element. (ILAYER is similar to LAYER – for the sake of simplicity, assume that almost all aspects of LAYER apply to ILAYER.) The LAYER object is not recognized by any other browser, including Netscape 6. While on the surface, Netscape 4 seems to recognize the DIV object (which is also a block level element), internally it “interprets” a DIV object like a LAYER object when it is treated like one. In Netscape, when you are addressing a standalone DIV or LAYER object, you generally address them as “document.layers.LAYERorDIVname”. You can address them with the plain “document.objectName” method also, but since the Netscape 4 implementation of Dynamic HTML is so quirky, it can be safer in some cases to address LAYER objects specifically with “document.layers.objectName”.

Another complication of Netscape 4 is when you have objects nested within other objects. For example, say you have an “image object” (IMG) named “myPic” nested within a layer object named “myBox”. You must address the nested object like so:

document.myBox.document.myPic

2. Next up is the IE versions 4 and 5 object model, which looks like this:

document.all.objectName.style.styleProperty

For example, if you are addressing the “visibility style” of the object “myBox” in IE you would write:

document.all.myBox.style.visibility

The first part of the DOM tells you that IE lets you manipulate “all” objects of the document (or practically all). This gives you much more flexibility than Netscape 4, as many people who have delved deeper into IE-proprietary Dynamic HTML have discovered. In addition, nested objects are no problem: they can be addressed directly. For the example above, the image object “myPic” can just be addressed like this:

document.all.myPic

3. Finally and most importantly, here is a look at the W3C standard DOM, which will hopefully become widely adopted by all browsers.

In the W3C DOM, each part of the document is treated as a separate object. In other words, where in previous browsers including IE5/Windows “document” was essentially synonymous with “body”, in the DOM “body” is treated as a separate, addressable object. The “document” object in fact encompasses the entire HTML on a given page, including the HTML tag itself. The BODY part and everything contained within is now addressed as document.body. The BODY object itself has all the elements of any HTML object: CLASS, ID, and so on.

Because every element on the page is exposed, you have to give each one a unique ID in order to be able to address them.

Let’s look at this in action. Take the example we’ve been working with, an object named “myBox”. In your HTML if “myBox” is a DIV object, the tag looks like this:

<DIV class="myBox">.......</DIV>

To reference this object in IE, you would write this:

document.all.myBox

In DOM-compliant browsers, you’d address the object like this:

document.getElementById("myBox")

As it implies, this method addresses the object (element) by its ID. As with the IE “document.all” method this means you can address any object directly.

Incidentally, the document.getElementbyId object is not quite the equivalent of document.all. That would be the document.getElementsByTagName object with a wildcard used (as in document.getElementsByTagName("*") which will return an array of all HTML element objects on the page. More about this later.

Exercise: Let’s play with a style attribute that many of you are probably familiar with – the visibility attribute. Write out the address for the visibility of a DIV object called “candybox” using the Netscape 4, IE and W3C DOMs and set the visibility to “hidden”. The answer is in the last section of this article.

Nodes, families and nested objects
So far, there isn’t that much different other than the specific addressing method between the IE object model and the W3C DOM, you might think. Essentially this is true – and for many of your Dynamic HTML tasks you can use your own cross-purpose substitute “object model” as I’ll explain later.

What is new, however, is the notion of nodes. In the DOM, each element of a document is not only an individual, addressable object, but is also part of a hierarchical family tree. This is an important concept to grasp because of the way that events (that is to say – mouse overs, clicks, and such) are handled within the document structure, and also because of some new methods which specifically refer to the child, parent etc. of objects.

Earlier on I described the Netscape 4 object model when referencing nested objects, and how, with the IE4/5 and W3C DOMs it was possible to conveniently address even a nested object directly by referencing its ID. However, a nested object is still, well, nested: it is a child of the container, or parent object.

Look at the “containers” model view of the web page above again. For the document depicted by this illustration, the red box (or object) is a “child” or nested element of the blue box, which in turn is a “child” of the orange box, and so on; while the green box is on the same level as the blue box – making it its sibling. And each box in the model is a node of the entire document. You will encounter the terms node, child, parent, and sibling many times when the DOM is being discussed.

One more thing to be aware of with the W3C DOM, is that literally every part of the document is a node in the document – even if it is not obviously “wrapped” in tags. Here is an example:

<P class="para1">This is a paragraph, and it contains
<B>a bolded section,</B> and
<span class="style1" class="someID">an inline element with a
style applied</span>
and other text.</P>


The object nodes making up this sentence are:

• The P object with the ID “para1”
• the node with the content “This is a paragraph, and it contains”
• the bolded (<B>) node with the content “a bolded section”
• the inline styled element node with the ID “someID” and the content “an inline element with a style applied”
• the section with the content “and other text.”

Reality issues
The W3C DOM will let you play with all the parts of your web pages as though they were little bits of clay. “So what?” you might be thinking. How is this going to affect your current pages? How are you going to support Netscape 4? Before we take a peek at the possibilities of the DOM, let’s deal with some here-and-now issues.

1. Browser branching strategies
Those of you who have been creating cross-browser DHTML pages have most likely been using a browser detection and branching script to serve up different versions of your JavaScript. But now that you see that Netscape 4 has such limited DHTML capability compared to IE 5 and Netscape 6, what should your strategy be? Should you serve up the same non-dynamic static content you might be serving to version 3 browsers to Netscape 4 users and urge them to upgrade to Netscape 6 or IE5? Or should you go to the effort of creating a third version only for Netscape 4 users, with limited dynamic content? The choice, is up to you and your client. At our company we have informally decided that until Netscape 6 is officially released, we will fully support Netscape 4, but once the new version is available we will actively encourage clients and users to upgrade their current Netscape versions and serve more or less static content to Netscape 4 users.

2. What about existing DHTML pages?
If you have already been creating DHTML pages that are cross-browser compatible, the bad news is that you will have to modify them to make them work in the new browsers. The good news is that modifying scripts that use the most popular DHTML methods should not be too painful. For example:

– Button rollovers where you are swapping the SRC of an IMG element:
Modify your addressing and they should work fine.
– Form validation: again, check your addressing method.
– CSS-positioning and animation: Check your addressing and style syntax (the W3C DOM uses “left”, “top” etc. as opposed to the IE “pixelLeft”, etc.)

Another piece of good news: any kind of dynamic content that is working in Netscape 4 and IE will work in the W3C-DOM browsers.

The bad news? You will most likely spend quite a few hours implementing those modifications. And if you have been using the LAYER element extensively, your work is really cut out for you.

3. Browser sniffing methods
The two widely used browser detection methods are as follows:

A. – Looking at the browser user agent and/or version, e.g. by looking at the navigator.userAgent value.

B. – Detecting for a specific property supported only by a specific browser. This method has become more popular because it’s short and simple. Here’s one that will detect for Netscape 4 and IE 4/5:

var N4 = (document.layers) ? 1 : 0;
var IE = (document.all) ? 1 : 0;


This little snippet tests to see if the browser supports document.layers or document.all, both proprietary properties of the respective browsers, and returns a true or false result. In your subsequent scripts you can just branch as follows:

if (N4) { // if N4 is "true(1)" then do this
}
if (IE) { // if IE is "true(1)" then do this
}


Logically speaking, this method is far more elegant. And you might think that this will work:

var DOM = (document.getElementsByTagName("*")) ? 1:0


This should, for all intents and purposes, detect for DOM-compliant browsers by seeing if they support the document.getElementsByTagName(“*”) object. However, reality in the form of Netscape 4 will bite back at you- since it will generate a JavaScript error and quit in its tracks when it encounters this object or in fact, any unfamiliar W3C DOM object. In order to maneuver around this, I have devised a simple workaround detection which should work – try it out here.

Another solution is to go back to detecting the browser user agent and version. But here also it’s not quite as straightforward as you might like, because for example IE 5 returns a value of “4” for navigator.appVersion! You must dig a bit deeper. So, I have created a page here so that you can take a look at the various browser properties which you can detect for in your script to assist you in your browser-sniffing efforts. Use it in good health.

4. A cross-browser home-baked object model
Many Dynamic HTML practices can be duplicated whether you are using the IE-proprietary model or the W3C DOM. For many purposes it’s convenient to create a kind of cross-browser object model for use in code that you will create for DOM-browsers and IE 5. One reason is the syntax of W3C DOM objects: getElementById has to be typed just so and yes, it’s case sensitive. To avoid having to type this accurately repeatedly and browser-branching all of your subsequent code, here is an example snippet which makes your very own object model which we’ll call “myDom”:

var myDom;
if (document.getElementsByTagName("*")) {
myDom = 'document.getElementsByTagName("*")'
}
else {
myDom = 'document.all'
}


Since IE4 does not support the wildcard method of getElementsByTagName (though IE5/Mac and the current version of IE5/Windows seem to), myDom is set to document.all in IE4, while all browsers that do support it will use document.getElementsByTagName("*"). In subsequent scripts you can use the following addressing method:

myDom.elementName.style.styleProperty
(example: myDom.someBox.style.visibility)


You can’t use this substitution for all scripts – for example, for some new DOM node methods described in the next section, or for those quirky cases where IE uses its own attribute syntax – but you will probably find this kind of coding most useful for a variety of tasks.

5. Learning syntax
Syntax is something you can’t avoid unfortunately – mastering the DOM means learning a whole bunch of new terms (some which are familiar, just with new names), and what’s more, many of the new methods have easily mis-typed case sensitive syntax. Substituting your own simpler syntax as described above may work for some things, but in the meantime, keep your references close at hand whenever you work.

A peek at the power of the DOM
Now that you know how to properly address the objects on a web page, what can you do? To whet your appetite, here are just a couple of examples using a handful of the new methods. Note that these pages have been tested to work in the most recent Mozilla build (no.16 as of this writing) and IE 5/Mac, the current most DOM-compliant browsers. They will not work at all in Netscape 4. An index of the test pages available is here.

1. Playing with the “visibility attribute” using the DOM This is the answer to the exercise question posed earlier. Click here for the answer.

2. Make an element move Here’s an example page that shows a function that may look quite familiar: making an object move on the page, aka DHTML animation. Here, you are changing a “positioning style attribute” of an object. You may observe that the addressing syntax is quite similar to that of IE 5, with the exception that you are addressing the object by the getElementbyId method.

3. Changing the background color style of an object The “background color attribute” is manipulated in this example.

4. Make an element and put in some content dynamically It’s now possible to create a brand new element on the page with JavaScript and to put some content in it. This test page shows this while also illustrating how the node/child concept works. The test page uses three methods which are probably very new to you: createElement, createTextNode, and appendChild.¹

Some final thoughts
Before you start unleashing the power of DOM on your pages, here’s something to ponder: no amount of DHTML splash and wizardry will make up for sloppily designed pages or poorly structured content. On the other hand adding “dynamic” elements to a page, however visually striking, without understanding what’s going on under the hood doesn’t really let you take full advantage of the possibilities. Another thing to consider always is backwards compatibility and what other browsers you are going to support – for example, most of the methods described here simply will not work in other graphical browsers such as Netscape 4, Opera 4, or iCab 2.

I hope that by reading this article, some key concepts about the W3C DOM and Dynamic HTML in general are clearer to you. This is a very introductory look, the first step in your preparation for the new browsers, and I haven’t addressed other issues which are important to understand such as “event handling”. If you feel confident that you have a good grasp of the ideas presented here, you’re ready to tackle more advanced topics and articles and start creating your own cool cross-browser DOM-based dynamic pages.

Happy coding!

Resources
These are additional resources to the ones listed in Part 1, which you should also take a look at if you haven’t already.

Resource hubs and learning/reference centers Netscape has a number of great resources for web developers which should all be in your bookmark list. Start with iPlanet or DevEdge Online, not to mention ViewSource Magazine. Also go to dmoz.org aka the “Open Directory Project”, and search for Mozilla, DOM etc. to come up with lists of useful articles to further your DOM education.

Unfortunately, the Microsoft equivalent to Netscape’s DevEdge Online,MSDN Online Web Workshop is not very useful as a W3C DOM-education resource since it doesn’t really clarify what properties, methods, etc. are proprietary to Internet Explorer and what aren’t. This site is the best resource for finding out what is going to work in IE and should be in your bookmarks too.

Individual online articles of note
Getting Ready for the W3C DOM by Danny Goodman. If the concepts I have described here are clear to you, go on to this article. Incidentally, Danny Goodman is my favorite DHTML guru and author – he can explain things remarkably clearly, though his books do tend to make more sense if you have a programming background so may not really be for novices. Look for other DHTML articles he’s written, mainly for ViewSource, plus his two books on the subject, Javascript Bible 3rd Edition (IDG) and Dynamic HTML: Definitive Reference (O’Reilly).

Updating Your JavaScript and CGI Scripts for Version 5 Browsers by Eric Krock. All about browser sniffing and more.

The DOM Compatibility Chart (Table 1) on the Netscape Standards Challenge page has links to many pages where you can test to see whether your favorite browser supports this or that DOM method, attribute and so on.

---

Footnotes
¹ Veteran IE 5 coders may wonder if the useful outerHTML, outerText, innerHTML, and innerText methods are included in the W3C DOM specifications. The answer is they are not. However, after listening to web developers Netscape has decided to include innerHTML (but not outerHTML) in Netscape 6, even though it isn’t part of the W3C specs. Test this out with a current Mozilla build with this test page (warning: the Mozilla implementation is still quite buggy). Hopefully the W3C will include this property in their specifications soon to make things “official.”
Back to content

Related Topics: Web Standards, Browsers