Cross-Browser DHTML: Conclusion
October 25, 1998
Square One
Building meta-languages to patch the differences between DOM's
will get you far in your cross-browser endeavors
-- but only so far. In some cases there are differences between
the DOM's which simply cannot be bridged. Microsoft's
DOM, for example, possesses the innerText property
which can retrieve or modify the text contained
with a tag. In other words, this property can "see" the
text inside a paragraph (<P>), allowing
for a code-based search of the page content, for instance. Netscape
has no equivalent or anything even similar.
Because there is no way for you to approximate this behavior in
Netscape, you must decide whether to maintain a
feature which uses innerText for MSIE users only,
drop the feature altogether, or re-think your approach.
Sure, that was a depressing example to start with, but it
happens. More often, even when there is no exact DOM
equivalent, you can achieve a desired effect in both browsers
by devising different techniques. For instance, consider
the popular DHTML "watermark," popularized by GeoCities.
The watermark is an object which remains fixed
in place on the page, even if the user scrolls the page up or down.
In coding this watermark, the programmer must
know when the user has scrolled the page. This is necessary to
determine the distance of the scroll and thus adjust
the position of the watermark so that it appears to remain in
the same visual location.
Microsoft's DOM sports a nifty scroll event
which can be set to fire when the user moves the scroll
bar of an object. This makes it easy to know when a scroll
has occurred. Netscape, on the other hand, does not
support this event. A classic cross-browser coding conflict
where meta-language tricks are of no help to us because
the trouble goes beyond mere syntax. Unfortunately, as far as
instruction is concerned, there are no clear cut
"steps" to solving this type of problem: you must
rely on creativity and a strong knowledge of each DOM.
In this particular case, the Netscape solution is inelegant but
effective: setup an interval timer (setInterval())
to poll the position of the page (window.pageX
Offset and window.pageYOffset)
every few milliseconds. Any time this value changes from the
pre-poll reading you know that the page has scrolled
and can work from there. As you can see, this is an entirely
different approach than was needed using Microsoft,
and one born only of deep thought and/or reading the code of
others' pages -- the latter being an excellent form
of study, although it should be stressed that "reading"
and "stealing" are not synonyms.
The More Things Change...
No doubt you'll continue to hear the promises of an upcoming
standardized Document Object Model. In Utopia,
this entire article would be rendered obsolete and we could
all code in cross-browser bliss. In fact, the DOM Level
1 Specification is now an official W3C recommendation. What
does this mean? It is difficult to know for sure. Microsoft
and Netscape may adopt this DOM and many of the specific obstacles
outlined in this article may well become antique.
On the other hand, a long-term outlook of the browser wars suggests
that browsers are evolving into distributed
operating systems, and as such, there is little incentive for a
truly standardized development environment.
Developing Web-based applications encompasses an increasing array
of technologies, of which the DOM is a part.
Even in the case of a common DOM, it is likely that other aspects
of web development will be tweaked into proprietary
domains, and as such, the issues raised in this article will
continue to rub.
That said, in the next article we will focus exclusively on the
Document Object Model, for understanding it
natively is the true key to mastering DHTML.
Cross-Browser DHTML: Function Libraries
Cross-Browser DHTML
|
