Reference -- but you're a bit off on your thinking..
obj is a reference to an object, a pointer if you will. parent.appendChild(obj) appends the object as a child of parent, the object obj referred/pointed to.
obj = something_else; doesn't delete object, but has obj reference a different object: something_else. The first object obj referred to, still has a reference: it's one of the childNodes of parent.
I know it's sort of confusing, but that's the way it works. An object doesn't disappear (get garbage collected) until it has lost all references to itself. In your example, there's still one reference to it.
If that doesn't make sense, post back and tell me what you do understand.. if I'm incorrect, please somebody correct me.
Thanks, I do understand, I've done a good deal of programming. But DOMs for whatever reason is really confusing me, maybe it is that one additional layer of referencing that I kind of see in DOM which is throwing me off. It's like when I think I've finally gotten to the object itself, I actually only got to the reference to an object.
So is it safe to say then that appendChild(obj) appends the object and not the reference. Because if it appends the reference, whenever that reference points to something different then the appended child will be something different.
Maybe you have a good suggestion to test what you have a handle on. I am just using alert(), but in the old days, with java or C++, if I had a handle on the reference I would get back with system.out.println():
ajsoadkj232r4 or something like that
or "hello world" if it was the actual object.
But with alert() half the time I just get undefined. And I don't know what that really means. Is there a better way to check?
Not really.. if I get undefined, I just just go back up one level and see where I'm at. After a while of that if I'm still lost, I just step back and re-evaluate what I'm trying to do.
I use paper and pencil for lots of stuff. innerHTML is a good one to alert() when appropriate. When you were working with Java and C++, did you ever work with trees? Binary or n-ary or something? Because that's what DOM is. It's an n-ary tree or Nodes. Nodes can be Elements....
Now I think you've confused things... the DOM is an API. The ECMAScript bindings are standardised, if you want to see the specification for them you can have a look at <http://www.w3.org/DOM/DOMTR>. Not all browsers behave according to the specification, however, and some browsers add proprietary extensions to it. A prime example of this is innerHTML, a proprietary extension added by iew that all browsers support for compatibility reasons, in difference to outerHTML.
As for browser implementation documentation, MSDN has a very complete and accurate one for iew (not so for iem). The Gecko DOM documentation is both old and incomplete, but it's still pretty good. Both of these are linked from my sig. (MSDN: DHTML and Moz: DOM, respectively)
Opera and Safari behaves pretty much according to the specification for what they support. Safari documentation is sparse, but Opera has a nice standards compliancy report.