<%response.buffer=true%> <% yere = year(date()) Response.Expires = 0 %> Advanced DOM

Advanced DOM

DOM vs innerHTML: We can write to elements using the DOM method, and using the proprietary innerHTML method. innerHTML is a non-standard (and not DOM or XML compliant) way to make quick changes on a page.

Here are two side by side examples of using "firstChild" of the DOM method, and then "innerHTML". Try it out, then try to insert a "bold" tag:

Change Node Value (DOM Version)    Change Node Value (innerHTML Version)

As you can see, innerHTML is able to insert the HTML, and fire it off, whereas the DOM version places the HTML we typed in as mere text. This shows the power of innerHTML over the DOM for quick changes. Think of the DOM as a scalpel, and innerHTML as a sledgehammer!

The controversy: Since innerHTML is not a standard, and has some issues, it is prone to much commentary. Refer to the following table for a quick overview of the advantages & disadvantages:

Standardized not Although not a standard, innerHTML is highly supported. AJAX & favicons aren't standards either, by the way!
Slow not innerHTML is markedly faster, for some purposes. This can make it attractive in the right applications.
Complicated not innerHTML is easy to use, the DOM is much more difficult to manipulate.
Flexible not innerHTML is good for quick changes to the contents of an established id on a page. It doesn't work well for making 'granular' (staged) changes, as it wipes out everything in it's path.

To view some of the discussion, review the posts at the following: innerHTML as Pot Noodles and also view tests on the relative speed of DOM vs innerHTML: Benchmarking DOM & innerHTML

Rendered Source: When we manipulate the DOM, (using either method above) we change the source code as it exists in the memory of the browser program. If we view the source in the normal way, we see it the page as it was when the page loaded, not after it has been changed via DOM manipulation. Wouldn't it be nice to have an easy way to view the HTML as it is changed, via the DOM?

Below is the same demo as the 'Change Node Value' above (innerHTML version) but adds an include file that allows you to click and see the rendered source, or the source as it is changed by the DOM: Change Node Value, Rendered Source

While working with the DOM, you can include the .js file in testing, if your HTML doesn't render properly: viewRendered.js

The key line in the source of the script above is this:

rendered = document.body.innerHTML.replace(/</g,'&lt;').replace(/\n/g,'<br>');

Here we're using the read capability of innerHTML to grab the entire contents of the rendered (in memory) body element and simultaneously chaining two calls to the replace() method to swap out "less than" symbols and replace them with &lt;, which is an HTML entity that nullifies the HTML and renders it visible.

The second call to replace() swaps the new line characters with <br> tags, so we can see the HTML presented on different lines.

In further code in the script, the entire is written into a new window and new document and popped on the screen as an aid to troubleshooting rendered HTML.

JS Template v2: The view rendered capability is built into a second version of our JS Template. I would start with our new JS Template Version 2, when building DOM applications.

IE Inconsistencies:With the current versions of Internet Explorer (Versions 5.5 to 7+) there are some inconsistencies that keep IE from being DOM level 1 compliant. One of these issues is the treatment of CSS classes from JavaScript. Remember that Microsoft's version of JS is really JScript, which is similar but not exactly JavaScript. In Microsoft's opinion, the word "class" is a reserved word in JS. Since that is the case, they decided to change the attribute "class" to "className" for purposes of using the "setAttribute" method.

Since this is not DOM1 compliant, there is a work around. We can use the older (what we call DOM level 0) object reference to change the CSS class of an element:

myObj.className = "newClass";

Since the Netscape/Firefox browsers are backward compatible to recognize this format, it is currently cross browser.  Here is an example of JS file that quickly "sniffs" for IE by testing for the IE only by checking for document.all and uses className if appropriate: ChangeClassIE.htm

More Attribute Trouble: IE has trouble with other attributes, for example the style attribute

Name vs ID in IE: Another anomaly of IE is it's treatment of confusing the 'name' attribute with the 'value' attribute. We are stuck with the 'old school' BOM 'name' attribute, as that provides context to the data submitted via the form to the formhandler. The "id" doesn't carry, but the "name" does.

IE currently confuses objects that both have the same name or id, and it's case insensitive! Here's a link describing a workaround: getElementById in IE

Mr. TBody: There are several other issues you may run into with the DOM of IE. For example, you can't add a <tr> element directly to a table using "appendChild". The workaround is to add the <tr> to the tables <tbody> element. Here is a very helpful site that addresses many of the issues you may run into working with the DOM of IE: Quirksmode

Stacking Classes: We can apply more than one class to an element simply by placing a space between the names of each element:

<div class="myBold myItalics myRed">

In the above three different classes are applied, with a single space between them. While this attaches all three classes to the element, it doesn't determine the order in which they are applied. This is determined by CSS cascade rules. We can change these programmatically via the DOM: stackClasses

Looping Through Classes: While the DOM makes it relatively easy to access object by id (getElementById) and by tag name (getElementsByTagName) a glaring omission has been the lack of a built in ability to access all items that have a particular class. Here's some background: No getElementsByClassName() method

While a void like was being filled by third party solutions, there was a movement within the browser development teams to create such a method even though it is not part of the standard. Therefore we have a version of getElementsByClassName() based on the work of John Resig and Dustin Diaz (detailed above) that will 'sniff' for the capability to run getElementsByClassName() natively before using a homegrown method based on the work of Resig & Diaz: getElementsByClass

It was problems like the above that led developers to create APIs to make it easier for developers to work with inconsistent browsers. Take a look and see what one of the above programmer's is the author of: John Resig

Table Manipulation: Below are three examples of a work in progress. It is designed to demonstrate how a table can be edited dynamically by the DOM. Each version should be studied in turn, for it reveals how the nodes can be manipulated, and data added to tables.


File Name Function Notes/Source
Dynamic editing of a table and it's contents via the DOM. Crawls the DOM tree, and demonstrates various DOM commands.

A couple of odd things are found by studying the above. For example, when you create a new <tr>, you need to start with a new <td>, load it with data, then load each <td> in sequence into the <tr>. Then when you enter the <tr> in it's spot in the table, it carries none of the formatting applied to the table! You need to then 're-apply' the class to the entire table, so all new elements (our <tr> loaded with <td>'s) have a consistent look!

Don't forget Mr. tbody - IE currently requires the <tbody> tag as a 'liner' inside the <table> tag - this is in the above examples so they will work in IE.

Want to really know the DOM? Spend some time with the above examples. Understand each in turn, and you'll be well on your way!

Loading Data into multiple IDs: Here was a problem sent in by a former student. He wanted the 'dates' to be hot, and trigger price and text changes on the page without reload: Cruise Schedules

Loading Flash Movies: The next example was the working model for a job done for Highline CC. It loads flash movies into a static position ala youtube: meToob

Look Ma, No document.getElementById(): In March 2009 I found out that you don't need to use document.getElementById() to access a DOM element in IE7+ and FF3. Simply calling the name of the element is sufficient. However, I don't know if this is a feature or a bug. It took me at least a couple hours to sort it out, and determine exactly what was happening, and now that I somewhat understand it, I can see other places this could cause problems: idTest

More!: For more info on DOM manipulation, study the following: XML Dom Advanced


Print this Page Back To Top

2000- <%=yere%> newMANIC INC, All rights reserved