Data Islands on IE 4.0

In my November 28 XML Toolkit column, I introduced XML data islands and explained how they work with Internet Explorer (IE) 5.0 and higher. With IE 5.0+, the browser provides special support for embedding XML data in existing HTML pages. This support mostly means a dedicated, special-meaning tag, . When IE 5.0+ encounters such a tag, it automatically creates an instance of an XML Document Object Model (XMLDOM) object based on the content of the data island. Furthermore, no matter where you put the tag in your HTML code, the XML code doesn't affect the page's rendering, but the XML content shows up in the page's Document Object Model (DOM).

Lucky you, if you know you can target your HTML client code to IE 5.0+ exclusively. Unfortunately, there are still plenty of applications where you simply can't assume that the browser has any special XML capabilities. As I demonstrate in this column, this shortcoming doesn't always mean that you have to abandon implementing XML data islands. I present two approaches—one for IE 4.x and one for all other browsers that support HTML 3.2 (e.g., IE 3.x, Netscape's browsers).

Being able to include invisible XML code in an HTML page is only half the task. The other half requires some tricks to read back that content and manipulate it locally. Manipulating XML code in most cases means parsing it, and how you do this mainly depends on how cross-platform your code needs to be. For example, using a Java applet might cover all cases, while using a COM certainly sounds better if you expect your code to run only on Windows platforms. Because this aspect is specific to the application, I focus on how to embed and retrieve XML code from within HTML pages viewed with IE 4.0 and Netscape Communicator.

IE 4.0 already provides great support for Dynamic HTML (DHTML). For our purposes, this means that after you've given an ID to a tag, you can later retrieve the tag by name and by running a script against it. IE 4.0 also provides good support for Cascading Style Sheets (CSS), which means that you can use the display style attribute to hide any tag you want. When you combine these two considerations, you get code similar to the following:

XML code

Wrap the XML code in any HTML or custom tag you want, making sure to assign it a unique ID and set the display CSS attribute to none. As a result, the XML source code will be accessible through

myXML.innerText

and won't affect the page's rendering. It's up to you to initialize a valid XMLDOM object to actually parse and manipulate the XML content.

HTML 3.2-compliant browsers make things slightly more difficult. You can't count on CSS support, and you can't expect to find a rich object model attached to all tags. A good compromise solution involves assigning the XML source code to an INPUT control marked as hidden:

Assigning a name attribute to both the INPUT tag and the container form lets you retrieve the XML code later through the following code:

oForm = document.forms["MyForm"];oInput = oForm["xml"];alert(oInput.value);

For Netscape's browsers, make sure to use the exact case for names, and make sure to wrap the INPUT tag with a FORM tag. Neither of these steps is necessary for IE 4.0+.