DHTML is the combination of several built-in browser features in fourth generation browsers that enable a web page to be more dynamic.
DHTML is a collection of features that together, enable
your web page to be dynamic. I think its important now to define just
what the creators of DHTML meant when they say "dynamic". "Dynamic"
is defined as the ability of the browser to alter a web page's look
and style after the document has loaded. I remember when I was
learning JavaScript, I was taught that you could use the document.write()
method of JavaScript to create webpages on the fly. For example:
<script>
document.write("This is text created on the fly!")
</script>
<input type="button" onClick="writeconent()" value="text">
Pressing the button was nothing short of a big disappointment. My
entire web page was erased, and I was left with only the text the
function produced.
With the introduction of DHTML, I can alter
content on a web page on demand, whenever I choose, without having
the browser erase everything else. That's what DHTML is all about.
The ability of the browser to change look and style even after the
document has loaded.
Developing successful web pages these days involves more than simply pumping out HTML tags. Ever-evolving towards a true development environment, complex web pages now grow out of a coalition of technologies, including Cascading Style Sheets, JavaScript (both loosely referred to as "Dynamic HTML"), and just around the corner -- XML. Consequently, web pages are complex organisms, far more advanced than their protozoan ancestors. Working with such an organism requires a thorough insight into its anatomy, and that is the basis and purpose for the Document Object Model. In this discussion we'll look closely at the "DOM," as it is known -- what it is, how you use it, and where it might be leading us.
The DOM is a Web programmer's ally, but as such, we must assume some Web programming experience. This article is not a tutorial on JavaScript syntax or Dynamic HTML; however, if you have developed any of the above, you will certainly be interested in understanding the DOM, even if you haven't heard of it until now.
The classic biology text, a cornerstone reference for students of the human composition, sets out to detail the components which make up the human organism; form and function. This Cartesian approach assumes that if we understand the characteristic properties of each building block we can understand the whole. More specifically, if we know how to modify (fix, improve, etc.) the components, we can modify the whole in a targeted way.
Quite similarly, the Document Object Model sets out to map the Web page for developers, as Gray's Anatomy maps the body for doctors. Broken down into its own components, the DOM details the characteristic properties of each element of a Web page, thereby detailing how we might manipulate these components and, in turn, manipulate the page. There is an important difference between the two references, however: while Gray's Anatomy is a descriptive source, subject to the design implemented by Nature, the Document Object Model is prescriptive, as it defines what components we may or may not modify, and how, as decided by a panel of developers.
The crux of this difference is that, unlike the components of the human body, the inventory of components which make up a web page are rather arbitrarily defined. Simply put, one panel of developers may decide to break the Web page down into a certain Set X of components while another panel may prefer to reduce a page into Set Y of components. Perhaps these sets overlap to some degree, but that, too, is arbitrary.
So, while Gray's Anatomy speaks usefully to all human bodies, a particular DOM does not necessarily apply to a particular Web page. Whereas human corpi are necessarily compatible, web pages are not, because web browsers are not. Microsoft and Netscape do not share the same DOM between their two browsers and, as a result, the anatomy of web pages differs between them as well.
The incompatible DOM's between both browsers have been the cause of developers' cramps, night sweats, and eating disorders -- not to mention lost productivity time and increased costs for clients. Until this situation is resolved, if ever (see end of article), there is an up-side: needing to know two DOM's may inspire you to become a DOM master, learning the DOM's intimately. This is a Good Thing, because mastery of a DOM is the key to great Web page development, even if the two corporate giants reconcile their differences. Before we delve into either DOM in specific, let's consider the composition of the DOM tself -- in other words, the anatomy of an anatomy! Both Document Object Models break down Web pages into roughly four types of components, summarized in the table below.
| Component | Description |
| Objects | Container which reflects a particular element of a page; objects "contain" the various characteristics which apply to that element (known as properties and methods); example: the submit object contains properties and methods relevant to the submit button in a form. |
| Properties | Characteristics of an object; for example, the document object possesses a bgColor property which reflects the background color of the page. Using a programming language (e.g. JavaScript) you may, via this property, read or modify the color of the current page. Some objects contain very many properties, some contain very few. Some properties are read-only while others can be modified, possibly resulting in immediate on-screen results. |
| Methods | A method typically executes an action which somehow acts upon the the object by which it is owned. Sometimes the method also returns a result value. Methods are triggered by the programming language being used, such as JavaScript. For example, the window object possesses a method named alert(). When supplied with string data, the alert() method causes a window to pop up on the screen containing the data as its message; e.g. alert("Invalid entry!"). |
| Events | An event is used to trap actions related to its owning object; typically, these actions are caused by the user. For example, when the user clicks on a submit button, this is a click event which occurs at the submit object. By virtue of submitting a form, a submit event is also generated, following the click event. Although these events occur transparently, you can choose to intercept them and trigger specified program code to execute. |
Since it seems that both DOM's outline the same types of page components, how do these two DOM's differ? By and large, the difference are in the details. One DOM may contain objects which the other does not; one DOM may support unique properties for an object which itself is common to both; one DOM may support events occurring at an object which are not supported in the other.
In fact, at first glance both Microsoft and Netscape's DOM's appear similar -- and they are. Both, after all, are reaching towards a similar goal -- to reduce the anatomy of the page into manipulable parts.