What is DOM Scripting?
First off, it's another one of those buzz terms you will hear over and over until you're heartily sick of it. Secondly, it's a new philosophy behind using Javascript that takes us beyond the bad old days of DHTML and code branching.
The Browser Wars
By releasing browsers which do not uniformly support those standards, browser makers are injuring Web developers, businesses and users alike.The Web Standards Project (WaSP)Mission Statement, 1998
While IE and Netscape duked it out for supremacy in the late 90s and while Firefox was still just a glint in Mr Mozilla's eye, Javascript was misused, abused and rewritten by the evil empires to make their browsers flashier and more 'wow'-factory than their competitor's. As a result our browsers today bear the mark of that legacy. Proprietary methods and properties still tend to be favoured by those who teach Javascript to a new generation of web developers, but things have moved on apace and these inconsistent code tricks have no place in our brave new world. Javascript is going back to it's roots. More and more developers are re-discovering Javascript in the context of it's original purpose: namely, manipulating the Document Object Model in the user's browser to add functionality without sacrificing accessibility. That's the philosophy I hope that I, and this site, abide by.
New Beginnings
Pioneers were busy separating presentation and structure, and exploring the frontiers of CSS. Incorporating JavaScript into the new way of thinking was not a top priority.Peter-Paul KochSeparating Behaviour and Structure
So how do we cast off the past? See with new eyes? Unlearn what we have learned? And just how have things changed for the better anyway? Why should we go to the trouble?
Consider these two examples of a pretty standard practice:
<a href="javascript:new window('http://www.example.com', 'newwin', '');">Blah</a>
<a href="http://www.example.com" onclick="new window(this.href, 'newwin', ''); return false;">Blah</a>
Clicking either link would open a new window with the defined parameters. What's wrong with these approaches?
The first example uses the javascript: pseudo-protocol in the link's href attribute and this tells the browser to execute the address as Javascript code instead of trying to follow the link. There's an obvious problem this causes: if the user's browser doesn't support Javascript, or has it disabled, the link becomes totally unusable. Now if you imagine this technique being applied to a whole page of links and visiting with Javascript disabled, all you end up with is a totally useless list of hover effects.
Our second example offers a huge improvement over the first. Instead of fouling up the href attribute, an onclick event handler is added to the link's code. If a user with Javascript disabled clicks on this link, the browser can still follow the URL as normal. A user with Javascript enabled gets the URL in a shiny new window. This is a first step on the road to making pages that use scripting more accessible. This example shows how you can add functionality without taking it away at the same time. But we can go further. Much further.