DHTML can do some pretty neat stuff. There's more to it than flash-style effects and the ugly square spotlight.

The first problem is that NS and IE comply to the dHTML standard in two completely different ways. In many cases, it's necessary to write 2 .htmls per page. Netscape has chosen to use the <layer> tag, while Micros~1's Internet Explorer treats DHTML more like an extension of JavaScript.

The second problem is that Netscape's implementation may provide better document control, but it relies far too heavily on a coordinate style of authoring. This would be fine if the backbone for web design weren't something as loose as HTML..... It's a good idea, but I don't know if the framework is well-suited enough yet.

Although with more substance than the 80s Cola War, this Browser War is just getting tiresome, and is just as much in the interest of the consumer. It's sad when the only way Netscape can keep their product alive is to make it 100% incompatible with their competitor. This divergence can only progess until they are two utterly unalike systems, with a full set of code required for each. Bleh.

...they've also prevented dhtml from gaining any popularity with this stupid squabble.
DHTML in Netscape 4.x and IE 4.x and higher is mainly different in that IE support dynamic styles, and Netscape doesn't. They each have different object model calls, and thus have to be dealt with differently, but you can special case them in. What I typically do is in a function onload(), I detect the browser string

var isNetscape = 0;

function myOnLoad()
{
     if(navigator.appName == "Netscape")
     {
       isNetscape = 1;
     }
     else
     {
       isNetscape = 0;
     }
}


Then whenever you need to make a call to a part of the dynamic HTML model, then I eval() a string for it to get the object. This way, there is never any incorrect syntax, especially if you use typeof() information to deal with any object failures.

In the realm of dynamic styles, there are many workarounds, but most of them involve document.write. In IE, you can directly write to a style (IE: name.style.property = newvalue), but in NS, this does not accomplish anything, with the exception beings the visibility CSS attribute: You can always turn an object "on" or "off" depending on what you need to hide or show with it.

Therefore, to work around this limitation for other items such as color, size, or what not, you need to inject new text where you want it; Netscape will change if you change the source on it. Now, document.write would normally write only to your top level document (where the <body> tag would start). However, Netscape has made your life marginally easier by allowing you to consider any Layer item a body element. This means you can do document.body.layers.layername.document.write "new text". With a properly set up JavaScript applet, you can place layer tags in the correct spot, and re-inject the correct text where you need it, when you need it.

The modeling system of NS is not as good as IE. There are more complicated handlers for events, and the ability to define custom events. Typically, only the Netscape <layer> tag can be affected at all at run time, while IE allows all manner of scripting, but prefers the nuetral tags <span> and <div>, because they do not affect formatting in any way on their own.

The scripting engines are also quite different. While they are both standard JavaScript engines (although Microsoft calls theirs JScript), Microsoft's is both more lenient and easier to debug. Netscape's however is more noticeable in case of a failure. Microsoft ships a debugger from their MSDN Scripting website called Microsoft Script Debugger that handles the task nicely, while Netscape has the clunky and strange JavaScript console (accessible by typing in javascript: into the browser). Both have their advantages; Microsoft's is a considerably nicer environment to get things accomplished in, seeing as it gives you a readable error immediately when something goes wrong.

All in all working with two established, competing products in the same realm is a difficult chore. You choose the lowest common denominator of functionality between the two, and work from there. Another hurdle in the DHTML world is that standards mean nothing; both sides break them somehow. It really comes down in the end to the smell of the dirt: who is implementing what. Your pages are documents of the browser, and whether they work or not with shipped code is your responsibility, not anyone else's. No one will blame Netscape or Microsoft when your app doesn't work.

Hello, and welcome to... The Future!

Here in the future, we call our Netscape browser Firefox, or Mozilla. In the future, we don't use eval() and document.write(), we use the Document Object Model (DOM). We never use document.all or document.layers, except to test what browser we're dealing with.*

DOM Level 2 introduced a suite of handy methods that allow developers to access single objects or lists of objects quickly and decisively. The two most common are getElementById() and getElementsByTagName(). These can be called on the document object itself, or any other object reference.

I have my object, now what?

There are all kinds of interesting interface features grouped under the heading of DHTML, but most involve

  • Showing or hiding an object
  • Changing the contents of an object
  • Changing a style property on an object
Here are a couple handy script snippets to perform these common tasks. They don't require browser detection - just enclose them in an if (document.getElementById) { } block to keep old browsers from choking.

Note: These examples assume that they're called with either

<SOMETAG onclick="myFunction(this)">

or

<SOMETAG onclick="myFunction(document.getElementById('OTHERELEM'))">

for performing actions on other objects.


Toggling an object's visibility

There are two CSS properties controlling visibility. One, display, effectively removes the object from the document. The other, visibility, just hides it. The caveat is that the latter doesn't change the space the object takes up. In the script below, substituting visibility for display should pose no problem.

function myFunction(obj) {
   if (obj.style.display == "none") {
      obj.style.display = "block";   // can also be "inline"
   } else {
      obj.style.display == "none";
   }
}

Mucking with object contents

This is especially handy for, let's say, an editable table where your user can add new rows for data on the fly. However, this is just a simple example. The really cool stuff is left as an exercise for the reader.

function myFunction(obj) {
   var contents = obj.innerHTML; // note we're ignoring Java's
                                 // capitalization conventions here
   if (contents.indexOf("edited") < 0) {
      obj.innerHTML = "edited";
   } else {
      obj.innerHTML = contents + ", edited again";
   }
}

If we wanted to be really slick, we'd create a new TextArea object or something, set its value property with our String, and attach it to the element represented by obj by calling the add() method on its childNodes collection. But we're not that slick.

Changing a style property

This is the same idea as in the display toggling script. The one thing that tends to trip people up is the syntax of style properties in Javascript. It's actually really easy to convert between them, though. They'll stay the same for one word property names and, for property names with dashes, replace the dashes with camel casing.

function myFunction(obj) {
   var otherField = document.getElementById("myOtherField");
   var isError = false;

   if (obj.value.length < 1) {
      isError = true;
   }
   if (isError) {
      otherField.style.color = "red";    // should actually use Hex
   }
}

Embrace the future! Refactor all those calls to eval() right out of existance and enjoy the power of the DOM!



More on the DOM: http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html

* ascorbic wants it noted that rather than check for browser, we should check for the availability of the method or property we want to use. In almost every case, this is true. But I still sometimes use document.all to test for IE when I need to make on the fly size adjustments, as IE has its own special way of calculating widths and heights. I actually have exactly one script where I do this, but it wouldn't function without a test for IE. Anyway, where possible, follow ascorbic's advice.

Log in or register to write something here or to contact authors.