Pat Farabee

Page in question:
http://www.howtocreate.co.uk/tutorials/javascript/dhtml
First, I'd like to say, nice stuff there!
I'm pretty new to DHTML, though not to javascript.  I used to do some crazy
things in javascript way back before CSS was around, including timer-driven
animations, Pre-Flash post-loading streaming content, all sorts of fun
stuff.  Of course, it was hard to make use of many of the concepts without
DHTML. :)
I have recently returned to javascript programming, so, I went looking for
some good primers on DHTML. Yours is definately one of the best I've found. 
I'm a stickler for 'hands off' inner workings of my functions, and your
detection approach is just what I was looking for.  (I've already modified a
lot of your code to suit my needs and programming style.. great stuff!)
I do have one issue, however, that you may not have considered, involving
object corruption.
One of the things I like about your approach is that it doesn't make
assumptions, and checks to be sure it does what is correct for the
particular browser implementation.  Besides being almost foolproof, this has
the benefit of not corrupting the objects with 'extra' properties that are
meaningless to that implementation.  Except, of course, where you have
actively chosen to make assumptions and corrupt the objects. :P
The most striking example is the section where you describe how to change
the background color of a div.. you go through painstaking effort to
describe how the different browsers accomplish this, and come up with a nice
way to detect the correct property, then tell the reader to disregard it all
and just use:
if( myReference.style ) { myReference = myReference.style; }
myReference.bgColor = '#00ff00';
myReference.background = '#00ff00';
myReference.backgroundColor = '#00ff00';
because "setting the wrong one will not cause any problems"
Unfortunately, setting the wrong one corrupts the object, and BREAKS code
like what you offered just a few lines earlier:
if( myReference.background ) {
 //supported by most browsers
 //like Gecko browsers and the IE series
 myReference.background = '#00ff00';
} else if( myReference.backgroundColor ) {
 //supported by most browsers
 myReference.backgroundColor = '#00ff00';
} else if( myReference.bgColor ) {
 //used by layers browsers
 myReference.bgColor = '#00ff00';
} else {
 //FAILURE, there is no way to change the background colour
}
So, the corruption I am speaking of is the extra background properties that
are meaningless in the particular implementation, and the assumption is that
the code isn't running in the same scope as "correctly" written code like
your first example... because if it is, it will break it.
Imagine, for example, someone modifying your "rewriting the contents" code
with the same assumption.. that creating an extra property won't matter..  
This code MIGHT work (haven't tested it, just for example), but would BREAK
the detection code you currently have if it is run on the same object:
//used by all current browsers
// (but now that we have assigned it, we can't check
// against it's existence anymore)
myReference.innerHTML = 'some <b>new</b> content';
if (myReference.document && myReference.document != window.document) {
 //used by layers browsers
 myReference.document.open();
 myReference.document.write('some <b>new</b> content');
 myReference.document.close();
}
There are some other examples you offer that do this as well.
Anyway, just something to think about.  Still like what you have to offer!
:)
--
Pat Farabee