DHTML != DOM - QuirksBlog

In his DHTML is dead. Long live DOM Scripting entry, Jeremy Keith proposes to rename "DHTML" to "DOM scripting", because "DHTML" is a buzzword and because (apparently) DHTML and DOM are roughly the same.

I don't agree. I see DHTML and DOM as two more-or-less separate layers of JavaScript that have more-or-less separate purposes.
As to the buzzword problem, that's our own fault. We should solve it ourselves, and not by changing names.

What's the difference?

Essentially a DHTML script changes the styles of certain HTML elements; it changes, for instance the top and left coordinates of a layer to make it move across the computer screen. A DOM script, on the other hand, changes document structure, for instance by re-sorting a data table or by adding extra fields to a form.

A DHTML script typically changes the style or className properties of HTML elements. A DOM script typically creates (createElement) and adds elements (appendChild) to the page.

In general (but only in general) DHTML scripts are simpler than DOM scripts. They typically create some sort of graphic effect the site's users (or its designers, in any case) consider cool or useful. In general (but only in general) DOM scripts tend to favour silent restructuring of the page without touching the presentation layer.

Of course there is a grey area between these two techniques, and there's no law that says a script cannot change both presentation and structure. Nonetheless DHTML and DOM scripting are not the same.

Stacking layers

DHTML and DOM are two layers of functionality added to the old Netscape 3 JavaScript language. DHTML came first; the Version 4 browsers started to support limited changes to the styles of some elements on the page. DOM came later: the Version 5 browsers started to support unlimited changes to the structure of the entire HTML document.

It's important to keep in mind that the DOM was added on top of the older DHTML functionalities, that it was never meant to take its place. The fact that we now have the ability to change document structure doesn't mean we don't need to change its presentation any more.

Hierarchical menus, for instance, could be created entirely through modern DOM scripting. If the user mouses over a link, you could create link elements and append them to the navigation. If the user mouses out, you could remove these elements again. No one would write such a script, however, since the point of hierarchical menus is to change the navigation's presentation, not its structure. Besides, the DOM script would be much harder to write and would face more serious accessibility issues.

The inescapable buzzword

The problem is that DHTML is a buzzword. Keith quotes a spectacularly misinformed definition of DHTML, clearly cobbled together by someone only marginally involved in the creation of websites. Keith is quite correct when he says "that's just plain wrong", but I feel he draws incorrect conclusions.

We shouldn't substitute "DOM scripting" for DHTML. We don't need a new phrase that is only marginally more correct than the quoted misinformation. We need to take back our technical terminology.

And that's the real problem, a problem not solved by the changing of names. If we did that, people googling for "DHTML" would still get the wrong definitions, and only the wrong definitions because the right ones would all be labeled "DOM scripting". Basically we're stuck with "DHTML" forever, so let's make the best of it. Let's de-buzzword it.

Our own fault

Besides, whose fault is it that newbies find the wrong definitions? Our own, I'm afraid. We web developers let the buzzword cat escape from the DHTML bag back in the nineties. We were bent on impressing people with yet another "new generations" of Internet "applications", but unfortunately we didn't know quite yet what we were doing.

This sort of enthousiastic evangelism creates a wave that takes years to dampen down again. For instance, we web developers started talking about standards back in 1998 (or even earlier), but it's only last year that I saw distinct traces of standards-compatible thinking emerge among my (non-technical) clients. These ideas take years to percolate.

It's the same with DHTML. DHTML has always been sexier than web standards, so the wave it created rose faster and became rooted in the mind of non-developers earlier than web standards. As a consequence, people who are only marginally informed of web development recognize it and may demand it "because it's cool".

That's the real trouble spot. We shouldn't change the names of our techniques, we should clear up the misinformation. We should gently correct the uninformed when they start to speak about DHTML while they really mean JavaScript in general, or even a user interface in general.

What is DHTML?

DHTML is the changing of the styles of HTML elements by means of JavaScript.
DHTML = CSS + JavaScript

For starters I suggest spreading this definition (as-is or slightly rephrased) as widely as we can. Next in the program would be the publication of a few good, solid, usable, accessible examples of DHTML that pay close attention to definitions and the difference between DHTML and DOM. I'll probably write a piece myself, but I hope others will help clear up this misunderstanding.

Comments

1 Posted by Angus Turnbull on 17 January 2005 | Permalink

Yup, let's de-buzzword it :). However, I'm not quite sure I agree with your modified definitions...

Older style DHTML scripts weren't necessarily restricted to changing CSS styles by the definition of "DHTML", more so by need for "cross-browser compatibility" and the corresponding use of Netscape 4 as a lowest common denominator.

NS4's sole mean of creating new content (aside from appending options to select boxes) was via its "new Layer()" function. Now, this was highly non-standard, but you could definitely append content to the document in a script that used new Layer() in NS4 and document.body.insertAdjacentHTML() in IE4+. I wrote several such scripts myself, such as JS-based hierarchial menus. And if you were to code something that was IE4-only then, you could come up with a script that has most of the functionality of modern DOM scripts (let's face it, innerHTML is/was damn flexible); adding forms fields and manipulating lists were quite easily done if required.

I see "DOM scripting" as a natural evolution of DHTML. All we've done is switched to a different, more capable and more standardised API for accessing and modifying the document contents, and expanded the repertoire of effects we can achieve. The underlying concept remains largely similar.

So yes, we should co-opt the term "DHTML" to include DOM scripting, and simultaneously make people aware of the needs for accessibility and modern standards compliance -- the new DHTML. It's still possible to write a completely inaccessible script as you quite correctly point out. DHTML can refer to modifying the document as a whole with JavaScript and the DOM; if it were restricted to modifying CSS style information, why wasn't it called DCSS to begin with?

2 Posted by Mark Wubben on 17 January 2005 | Permalink

Interesting post.

Your definition of DHTML misses one thing though: how do we find those elements and the styles we want to change? Yep, via the DOM. What I think you are describing by DHTML *is* the JavaScript we saw in the nineties.

DOM scripting is quite a fancy term, but it's virtually impossible to write a script which doesn't use the DOM - be it a presentational script or a script with changes structure.

I do agree though that JavaScript is to be used *on top* of the structure and presentation layer. Thus, seeing JavaScript as the third layer, perhaps we could call it "behavioural scripting"?

3 Posted by ppk on 18 January 2005 | Permalink

Both of you have a point, but I'm not sure if that means my DHTML definition is wrong.

Mark, of course you need the DOM to find the elements you need. However, my definition of DOM scripts is that they *change* the document structure, and that's a different thing.

Angus, I didn't know you could add content in the Version 4 browsers (and I wonder if it ever worked properly in Netscape 4). However, you could see this functionality as a sort of "proto-DOM scripting", especially since it didn't grant access to, for instance, text nodes.

The most important thing, to me, is to stick to terminology people know. "DHTML" and "DOM" have come to mean different levels of scripting, and I feel we should keep it that way, even though (as is shown here) defining them is difficult.

4 Posted by Alex Lein on 18 January 2005 | Permalink

Why do they need to be separate? Using your definitions, I typically use a kind of hybrid DHTML/Dom Scripting with all my scripts. Doesn't DHTML stand of Dynamic-HTML? Wouldn't you think that "Dynamic" means that the HTML not only changes it's properties, but can create and destroy objects within itself as well?

Whenever any of my less-nerdily inclined friends asks me what DHTML means, I basically tell them your new proposed definition. However, I don't classify DHTML and DOM Scripting as two different things intentionally.

"DOM Scripting" is crippled today (as DHTML was by NS3/4) because Dynamically created INPUT and TEXTAREA elements do not submit their values in POST of GET. This is a necessary step to separate DOM Scripting from DHTML, since any created elements cannot add functionality, they can only be used for display purposes.

5 Posted by Mark Wubben on 19 January 2005 | Permalink

ppk, personally I consider the style object to be part of the DOM... and there's the problem with all this, it's way too subjective!

6 Posted by __Maad__ on 20 January 2005 | Permalink

On the other hand, Who writes a "DOM script"? You write javascript that happens to use the DOM API, and probably does other things too. Very few meaningful scripts are islands, after all.

This semantic mess is why umbrella terms like "web application" (an arguably vacuous term) take on popularity from those who would rather not patronize their work simply as "DHTML" (which is often associated with silly animating/scroll-tracking DIVs and the like). Sometimes people want/require these "buzzwords" for valid reasons. We should simply be clear, however, or invent a new term that is precise in its definition from the outset. My preference is to keep all these terms separate and be clear about what I am using in a given piece of work when discussing it with another person: "I'm using javascript + DOM + the xmlhttprequest object for this particular part of the application", for example.

7 Posted by y5 on 28 January 2005 | Permalink

"there's the problem with all this, it's way too subjective"

Mark, that's exactly what ppk is saying here, and his point is to offer a solution. He wants to pin down each term with a definition, hence removing the subjectivity.

8 Posted by Bamboo on 1 February 2005 | Permalink

I think Maad has nailed it here. There is no such thing as DOM scripting. Rather, we use the DOM in our scripting whether that be Javascript or PHP or whatever. The DOM itself is not a scripting language. To call something DOM scripting seems like a bad idea because it confuses the definition of the DOM.
As for DHTML, I don't think that many people actually seriously rely on a working definition of what this is. Couldn't we just say DHTML has evolved into modern active pages? You can still build a static page that is extremely rich with no scripting, many people do. Wouldn't it be easiest to say that DHTML is simply defined as a Dynamic page and leave it at that? That way it can remain a useful term with a broader definition.

9 Posted by JAT on 3 February 2005 | Permalink

DHTML = Dynamic HTML.

It's always meant having the ability to update the presentation via client-side manipulation. Sometimes that means altering CSS tags to add/remove visiblity, change colors, or what have you. Some times that means, updating the contents of selection object, or altering the order of the elements in a table.

I don't really see the need to differentiate. DHTML means coding on the client end so that you don't have to make a trip to the server to rebuild your page. Some times it's a good idea and sometimes it's not. Just like pretty much everything else we do on the web.

10 Posted by gigablast on 6 March 2005 | Permalink

Alex Lein wrote that dynamically created INPUT and TEXTAREA elements do not submit their values in POST of GET.

This is absolutely wrong, as it works correctly in IE, Mozilla, Opera, Safari, etc.

You can dynamically add form elements using DOM scripting, and they will be submitted in the GET or POST. It's highly useful for allowing users to add entries to a form.

11 Posted by Myrth on 24 August 2005 | Permalink

to gigablast: mozilla doesn't add elements to document.forms[] collection, if it was added thru innerHTML to one of the elements inside the form.