New free article – From DHTML to DOM scripting
I just published a new longer article (40 pages) trying to explain the differences between DHTML and DOM scripting. The article explains what DHTML, the DOM and DOM scripting is and shows how to create a web page with dynamic elements like tabs, a slide show and a big product shot in both ways.
- Check “From DHTML to DOM scripting”:http://icant.co.uk/articles/from-dhtml-to-dom/ now
The DHTML explanation is annotated with explanations why some of the techniques are a bad idea and the DOM scripting version explains why some of the assets are good ideas. As a summary:
DHTML issues:
- Script dependence – Users without JavaScript get stuck or get elements that only work with JavaScript but don’t do anything for them.
- Mixing presentation and functionality – If you want to change the look of the effect you need to hack around the JavaScript.
- Assuming functionality without testing for it – what it says
- Keeping maintenance JavaScript based – Maintainers are expected to change the script when they want to change the effect, and search through the whole script.
- Mixing HTML and JavaScript – what it says
- Blaming the user – Users get messages like “you cannot use this as your browser doesn’t support it, update your browser” instead of just not getting the functionality if it is not 100% necessary.
- Taking over the document – one onload to rule them all
DOM scripting assets:
- Progressive Enhancement – check if things are available, then apply those dependent on them
- Ease of maintenance – keep the maintenance as easy as possible via dynamic CSS classes and properties at the beginning of the script
- Separation of Presentation and Behaviour – add dynamic classes instead of changing the style collection
- Separation of Structure and Behaviour – use dynamic event handlers and generated elements instead of onclick and NOSCRIPT
- Using modern event handling – more than one onload please
- Avoiding clashes with other scripts – avoid global variables and encapsulate functions as methods in an object
Of course, you can disagree :-)
April 1st, 2006 at 12:56 am
March 29th, 2006 at 7:53 pm
Hi Christian, I posted a short rant on your use of the word DHTML on my site. I also have a few comments on the article itself.
Actually IE 5.0 was the first browser to implement a version of the W3C DOM. See this browser timeline.
Assuming functionality isn’t a bad thing, usually. When the specifications say
moveTo()moves a window, you can assume it does. Who could have known that, one day, a browser, which at the time of writing isn’t even released yet, would change this?Indeed, not the best way, today. Things have changed, but you can’t blame DHTML for that.
Oy, could it perhaps be that the CMSs never took this into account?
How exactly is that special to DOM Scripting? Sounds like a programming practice to me.
March 29th, 2006 at 8:09 pm
Hello Mark,
correct me if I am wrong, but the whole idea about calling what we do with best practices in mind “DOM scripting” is that we provide a way to allow potential users of scripts to distinguish between the good and the less good or outdated scripts. In the peak time of DHTML everything was called DHTML that used JavaScript and altered HTML or style settings.
DOM scripting is not a new programming language, it is a cleaner way to deal with the same issues. If you want to follow the same principles and call your things DHTML fine by me, however it’ll make it harder to find your good work in a sea of quickly developed flashy stuff.
As for the CMS part – this is not what CMS are about IMHO. They have the word content in their name, which means you should manage content with them and not the site’s look and feel, behaviour or programmatic logic. That a lot of CMS try to allow for the lot is one reason for a lot of tagsoup on the web.
March 30th, 2006 at 9:23 am
Weird, your article implies DHTML means no DOM usage. Manipulating a HTML Document using DOM is still DHTML.
You’re just comparing bad DHTML with good. Yes, using DOM to acheive DHTML is a good idea. All your article says to me is DHTML without DOM is old-school.
Your DHTML issues are not unique to DHTML-DOM (DHTML minus DOM). All your issues could be present in a bad DHTML+DOM implementation.
DHTML issue #5: document.write() is not a DHTML method in my book. Valid DHTML methods must be usable after the document has loaded.
I don’t think your DOM scripting assets are unique to DOM either, you don’t need to use the DOM to solve those problems, and using the DOM doesn’t guarantee to solve them.
DOM scripting asset #4: You haven’t separated structure and behaviour, you’ve just moved the coupling to your DOM script. However, this is a damn good idea, especially if you can drive all your DHTML generically from classnames, or relative DOM traversal.
DOM scripting asset #5: I seldom use the body.onload event, it doesn’t fire until every last component has loaded, which in a many cases can be too late. The number of times I’ve been using a website where focus jumps to the username field whilst I’m entering my password.
I feel awful for saying this because you’ve obviously worked hard on it, but I think the article is misleading. What’s the difference between DHTML and DOM?
March 30th, 2006 at 9:33 am
Lee: Easy – DHTML is a marketing buzzword and the DOM is a web standard. As there is no definition of DHTML in the web standards it is hard to tell what could be called DHTML.
DOM is a standard, but nothing that is unique to JavaScript. DOM scripting is a modern approach to scripting dynamic effects with DOM, JavaScript and CSS.
The point of this article is not to say you should call all your work DOM scripting from now on. It just shows what was a bad idea in DHTML but more or less common practice – and still is a bad idea in DOM scripting but shows how to do it better.
You can call this “best practice” way of scripting “Jennifer” for all I care, but I personally consider “DOM scripting” catchier :)
March 30th, 2006 at 12:22 pm
This is confusing because “DOM Scripting” is DHTML! http://www.w3.org/DOM/faq.html#DHTML-DOM, DHTML allows HTML documents to be animated.
Your article seems to be distancing DOM Scripting from DHTML when in fact DOM Scripting is actually the recommended way of doing DHTML.
It’s fine to call the recommended way of doing DHTML “DOM Scripting”, just don’t refer to the bad way as “DHTML” because it’s misleading.
March 30th, 2006 at 12:42 pm
Can you please tell me where this paragraph defines DHTML as scripting the DOM?
I only can see the same argument that I had in my previous post, that DHTML is not a standard but a vendor term and therefore IMHO should not be used to describe dynamic scripting of the DOM via JavaScript.
This is a bit of a fruitless discussion as you see DHTML as a legitimate description of good coding practices whereas I really think the overuse of it as a label offering obtrusive and badly designed scripts has made that impossible.
March 30th, 2006 at 1:30 pm
No, DOM Scripting (over a HTML Document, to create dynamic effects) is DHTML, anything which does this is DHTML, but not the other way around. There are many ways of doing DHTML, DOM Scripting is one of them. So I don’t know why you’re looking for that in the paragraph.
Of course DHTML is not a standard, just like AJAX and REST aren’t. It’s just a term which describes and idea. There are good ways and bad ways of implementing everything.
Therefore, I also absolutely do not see DHTML as a legitimate description of good coding practices, but bad implementation of DHTML does not mean DHTML is bad. Saying DHTML is bad is invalid, because it depends on how it has been implemented.
One can use DOM Scripting to do DHTML. According to your article, this would appear to be contradictory, saying they are two distinctly different things, but in fact it’s not. Even the paragraph from w3.org says there’s significant overlap.
March 30th, 2006 at 1:55 pm
So how would you distinguish between good and bad coding practices in one or two words?
You are absolutely right in your argumentation from your point of view of what DHTML is.
The DHTML I am talking about in the article is the term non-developers or junior developers use. Ask around what DHTML is and you are very likely to get an answer like “moving things around on the screen”, which is a sexy effect to achieve when you really don’t know much about the language you try to learn and stops you from really looking into the structure and the logic of it. If we don’t stop using an ill-fated term like this we don’t stand a chance getting to develop clean JavaScript solutions.
I still don’t buy the idea of the term DHTML, as there is no such thing as “Dynamic HTML“. HTML is a markup language that describes content and gives user agents instructions what to render as what. SVG is an XML format and renders as graphics, should we call SVG “designXML” now? Even in its naming the term DHTML mixes two different tiers of web development, and this is just not practical.
March 31st, 2006 at 9:49 am
Without being unfair to your otherwise excellent article, I’d use “Unobtrusive JavaScript” for two reasons:
1/ When I read the article, my gut opinion was that it discussed unobtrusive JavaScript more than comparing DHTML-DOM with DHTML+DOM. If all your DHTML-DOM examples were unobtrusive, the article would have better covered the differences.
2/ It’s a term we have come to know and love, thanks to you.
I know what you mean when you say there’s no such thing as Dynamic HTML, but the same could be said for “Unobtrusive JavaScript” i.e. I can’t do type=”text/unobtrusive JavaScript”. As Lord Denning said (about various things): “This is perhaps like the elephant: Difficult to describe, but instantly recognizable”.
April 1st, 2006 at 9:56 pm
Wow, great article Chris. That will keep me busy for a while. Thanks and good luck with the writing.
April 5th, 2006 at 12:40 am
The terms “DHTML” or “Dynamic HTML” from the very beginning of their use were unapologetically imprecise and steeped in the marketing tea of competing browser makers. The value of these terms was never high and has become less over time.
“DOM scripting” on the other hand represents a precise set of objects and practices. In fact, it proclaims a better way. If DOM scripting is what a developer is doing, then it is far better to use that more precise term.
March 21st, 2007 at 5:17 pm
Thanks for an entertaining and very well written article, with a hilarious demo page.
I find the concept DHTML rather vague. Instead I believe you have made a very good point in showing how good programming practices in general (such as modularization, separation of concerns, avoidance of namespace pollution) can be applied in web design, where they until recently have been mostly absent.
small note:
>the attribute with the name attribute
is perhaps more clearly explained as
>the attribute with the name attribute to newvalue
March 3rd, 2009 at 9:27 pm
Nice example of progressive enhancement! I’ve been experimenting with your sample code and found a rather odd behavior with IE 6 – if a table is included in any of the tab div sections the table content is not shown unless the window is resized. All content displays fine in Firefox and Safari, but in IE only the non table content is shown. For example:
…
Flat Details
firstrow
2ndrow
Spacious 22m2 flat in excellent condition
…
Any idea what is going on with IE?