Hidden Frames and Layers
eval() trick would work though.
There's another more serious shortcoming in this technique, which is to do with the way
web browsers load pages and web servers respond to simultaneous requests. The outcome of that, is that
you simply cannot be sure when that frame containing the hidden data is loaded. The necessary tricks
to set synchronization flags require
onLoad handlers in the data frame and the ticker, which both call
functions in the parent frameset container. That's guaranteed to be loaded, because otherwise the child
frames wouldn't have been requested. You can then set semaphores to indicate loading is complete and
then access the data conditionally on those semaphores being set. It's all a bit too uncertain and any
connection failures and loading errors can cause even more problems.
DOM navigation of document structures has been proven to be unworkable. Both IE and
Netscape 6 provide the same API to the document content. Unfortunately, they treat whitespace and
textNodes differently, and so the
childNodes collections that might have been useful for
walking down the tree are of no use, because none of the index values correlate between browsers.
Indeed, IE on the Macintosh and Windows platforms are even further apart than the Macintosh versions
of IE and Netscape 6.
Setting those problems aside, it's quite desirable to use DOM techniques to extract
content from within the same document that the
SCRIPT tag is located.
If only the DOM implementations provided a way to examine the child nodes of an object
in a consistent manner, this would be a really useful technique, because the structured
approach is widely supported. The biggest problem with DOM is that the interstitial text between
DIV tag is treated differently in IE and Netscape. In fact, IE on Macintosh and Windows platforms
are significantly different. This means that the
childNodes collection on each platform puts the
DIV blocks in completely different index locations in the collections. You can fix this by
manually filtering the
childNodes collections to discard all the
That way you could walk down the
The DOM situation is under development and the DOM Level 2 traversal and range module provides the necessary filters, node iterators and tree walking capabilities that we currently lack. Without these, the DOM implementations are really so incomplete as to only provide marginal help over and above what we had with DHTML.
Structured DIV Blocks
Building a document structure from nested
DIV blocks has the same
disadvantage of needing to be statically included in the same document, although that can be done
with a server-side include. It has the major advantage of providing structure. There are limitations,
such that the
ID values need to be unique and HTML 4 compliant in their naming
conventions. That may cause problems with generating ID names algorithmically, so they can be
fetched more easily.
So, here is an example data block formatted with
DIV tags and showing how
to build a simple
childNodes filter that produces consistently the same list of
childNodes on all browsers:
In the News Online ticker, the
DIV blocks are structured so that the content is a collection
of several story headline texts and the associated links where we can see a page full of text about the
story. The additional meta-data is just an item count, so we know how many stories there are. We could
store other meta-data too. We could store some controls for the ticker speed, and how often it should be
The entire story content and meta-data tree is also enclosed in a single top-level
DIV block. This is helpful, because we can set the style of the block so its
display: property makes the
DIV block invisible. That's also shown in
this simpler example. Without that, the content of the
DIV blocks would be visible.
On a site, such as News Online, the news story data for the ticker is published into a separate file and a server-side include is used to insert it into the outgoing response from the web server.
Created: November 8, 2001
Revised: November 8, 2001