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.
As to the buzzword problem, that's our own fault. We should solve it ourselves, and not by changing names.
These are the defintions of DHTML and DOM scripting:
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
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.
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 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.
A lot of people looking for scripting resources might try googling for DHTML. If they do, they'll discover a lot of browser-based scripts dating back to the nineties.
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.
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".
So let's correct the uninformed.
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.
Let's take back our terminology.
I’ll be around at the following conferences:
Comments are closed.