^.^ Looking for sexy local singles ? TRY FREE :)
When the version 4 browsers came onto the scene they effected a small revolution in web design. While their support for new standards like CSS was poor, they held within themselves great promise. One of the buzz-words coined at this time was DHTML — Dynamic HTML — which was touted to end the viability of boring, static webpages. Here are the facts on this intriguing technology...
So what are we talking about here, exactly? What is DHTML? Most web developers don't actually know, or only have a vague idea of what the term means; a consequence of the fact that no official specs or definition have ever been issued. The accepted definition for this new item in your nomenclature is the changing of the style declarations of a HTML element through JavaScript.
When you execute a change to the style declaration of an element, the change is registered immediately in the browser window, without the page having to be refreshed. You can have a reader interacting with a single page, hiding and showing elements, moving things around, changing colours and generally messing everything about — and never have to call for further files or load new pages.
Before the advent of DHTML, we could only use static HTML. When you load up a page, aside from the odd JavaScript rollover, the view didn't change in appearance until you moved on to the next page. Elements were placed onto the page in a natural flow according to the order they assume in the HTML code. DHTML, being dynamic and all, allows you to disrupt this natural flow by taking elements out of the page and displaying them elsewhere, on command from user interactions. Clicking on links and buttons can allow all sorts of things to take place. The order things come in the source code can be made largely irrelevant with absolute positioning.
So if DHTML is so great, how come it's used so little in mainstream websites and is commonly relegated to web designer's personal experiment sites? Well, DHTML has a shadowy past behind it. Much noise and commotion erupted when it was first announced at the same time as the version 4 browsers were released. At the time people really thought this was the next big thing and would spell the end for the old-style web of unmoving text and images.
DHTML's problems as a technology began because at this point it was not supported by the version 3 browsers, who still retained a considerable share of the market. Clearly, this made it impractical for use on any commercial site. Further to this, as rivals both Netscape and Microsoft had no interest in working on a standard method of DHTML, and so a script which worked in one of the big two browsers would not work in the other.
Netscape's implementation of DHTML paled in comparison to IE4's, but due to a slightly earlier release and more complete documentation, it was adopted as the standard browser for DHTML. Quickly however, the relative difficulty of programming this new breed of script, along with the ridiculously disparate browser support, set a number of people out on a crusade under the banner that DHTML was dead. Many working designers nodded sagely and the issue was laid to rest.
A few right-thinking individuals argued the point however, contending that DHTML had yet to come into its own, as the time was simply not yet right for its true inception. DHTML is not really a gracefully degrading technology, so you need to be sure that the vast majority of your audience will be able to support it. With the disappearance of version 3 and, soon, version 4 browsers from the browser landscape, we will soon be able to predict with certainty that DHTML scripts can be safely used on our pages.
