8

I'm a bit confused by DOM nodes, mostly just the terms.

Previously I thought the DOM was what I saw in my inspector, nothing more & nothing less. Now I'm aware of functions such as document.createElement() which create DOM nodes that have my document as a 'context', but do not have the document as a 'parent'. Does document.createElement() create "out of DOM nodes"?

And isn't that term a misnomer? A "node" is synonymous with a "DOM node" or "HTML Element", per my understanding. Isn't it bad naming to call something an "out of DOM node", when nodes are things in a DOM? The term seems self contradicting.

To add further confusion, there are new concepts like retaining paths, detached DOM nodes, hanging DOM nodes, shadow DOM, document fragments, etc.

Which of these terms are synonymous? Which are misnomers? And which are actual specs (bonus for linking to specs).

Improve this question
9
  • 1
    That nodes can exist in the DOM doesn't mean they have to. It's like a person can sit in a car but is still a person outside the car, or in a bus. And all those terms are perfectly google:able (including node).
    – Jan
    Commented Jul 5, 2015 at 4:09
  • I'd been googling for over an hour before posting this question. Your comment is unhelpful because saying nodes can exist "in" or "out" of the document is something I acknowledge in my question. I'm looking for a detailed answer explaining differences between parent & context, node & element, etc... or an answer that states they are synonymous terms with a link to a spec to back it up.
    – Josh Ribakoff
    Commented Jul 5, 2015 at 4:20
  • 1
    I couldn't answer. I think of some as colloquialisms, but may be surprised to find out that some (maybe all) are well-defined terms. As such, I'm not qualified to answer, except to say that I don't find them to be misnomers and IMO, not terribly confusing. Hopefully someone else will offer you a more satisfactory answer,.
    – user1106925
    Commented Jul 5, 2015 at 4:53
  • 1
    Thanks. "Misnomer" may have been a bad choice of phrasing on my part. I too feel that I have a "good idea" of what is what, I'm just looking for something more definitive than people commenting and saying "well duh...." (in effect). Thanks ;)
    – Josh Ribakoff
    Commented Jul 5, 2015 at 4:54
  • 1
    Yes, "out of DOM node" is technically a misnomer. DOM is an API not an object. It should be "out of document node". But it's very common to refer (incorrectly) to the document, when it is accessed via the DOM API, as the "DOM". Most people know what is meant from the context.
    – Alohci
    Commented Jul 5, 2015 at 8:34

1 Answer 1

Reset to default
6

And isn't the term "out of DOM nodes" a misnomer?

No. First off, when talking about "the DOM" regarding HTML, it's referring to the HTML DOM. A node can exist in the HTML DOM or not. A node (in the sense we're talking now) is just the smallest self-containing part that CAN constitute or be part of a DOM.

As such, it could exist anywhere and still be a node. An engine is still an engine if it's detached from the car. It just not very useful until it's put in the "right" place.

A "node" is synonymous with a "DOM node" or "HTML Element", per my understanding.

A node CAN be added to the HTML DOM and it CAN be a HTML Element, but it doesn't have to be. In HTML, a text node is also a node for example. And a node can exist in a HTML document or XML document or RSS document or...

Or it could be a node which is an HTML element but exists outside the HTML DOM, only in memory for example. Which is the case when creating nodes dynamically.

Isn't it bad naming to call something an "out of DOM node", when nodes are things in a DOM? The term seems self contradicting.

Per the above, no, it's not. An engine is still an engine and a node is still a node.

To add further confusion, there are new concepts like retaining paths

"Retaining paths" has nothing to do with the DOM, but rather JavaScript. It means that as long as there's still a reference to a variable/object anywhere, that object isn't garbage collected. As soon as all methods/functions/DOM elements that are "using" the object are garbage collected, so is the object.

It's basically just about garbage collection/memory leaks. It only concerns the DOM in that everything that is in the DOM is being "used" and should be retained.

detached DOM nodes, hanging DOM nodes

"Out of DOM node" and "detached DOM node" would be the same thing, and I'm guessing "hanging DOM node" although I've never heard that one used. They all seem to imply nodes that have been removed from the DOM but are still retained in memory through JavaScript.

And these concepts aren't new, JavaScript has done this for a looong time. If they seem new it's because people talk about them more.

shadow DOM, document fragments, etc

These are clearly specced in the HTML DOM specifications. A quick answer is that Shadow DOM again is a JavaScript thingie, and it's about giving your elements a protected scope as well as separating content from rendering. Seem confusing? That's because this is an entirely new question in itself and you really should read up on it.

Some links to get you started:

http://www.w3.org/DOM/
http://www.w3.org/TR/dom/
http://w3c.github.io/webcomponents/spec/shadow/
http://www.w3.org/TR/2014/REC-html5-20141028/

Improve this answer
5
  • Thanks. When you say it could exist "anywhere", is there a definite list of places (for example, one such place is in JS memory due to retaining paths, which I learned in the last few months when debugging memory leaks in a kiosk app). Another such place is in JS memory due to calls to document.createElement(). Just wondering what else there is? I will read these specs... and marked as accepted since it answers original question! Exactly what I was looking for. Your original comment was like telling me I suck at Geometry. This is like explaining that squares are rectangles. Thnx.
    – Josh Ribakoff
    Commented Jul 5, 2015 at 6:30
  • 1
    Retaining paths has nothing to do with the DOM, but rather JavaScript. It means that as long as there's still a reference to a variable/object anywhere, that object isn't garbage collected. As soon as all methods/functions/DOM elements that are "using" the object are garbage collected, so is the object. It's basically just about garbage collection/memory leaks. It just concerns the DOM in that everything that is in the DOM is being "used".
    – Jan
    Commented Jul 5, 2015 at 6:36
  • I see. But retaining paths do cause [DOM] nodes to exist in memory after removing from the HTML document. It still seems weird to think about "where" these exist, since I can't inspect them (other than doing heap snapshots). I guess I should read these specs a little better before asking too many open ended questions, though. For example your comment implies nodes are objects. Based on this I should probably read up. I knew nodes could be wrapped in objects, but I wasn't aware they are objects. Still not sure if we're talking about C++ (browser internals) or JS (userland), for example.
    – Josh Ribakoff
    Commented Jul 5, 2015 at 6:40
  • I don't think they should retain unless you explicitly keep them alive by storing them in a javascript variable/property. I might be wrong, not an expert on this, and this should also be browser-specific. Regarding "anywhere" it could also be in a backend app for example. Creating XML nodes in C#. You need to start thinking about "nodes" in the abstract sense, it's just a building block. As such, anything that can "build" can hold it. "Still not sure if we're talking about C++ (browser internals) or JS (userland)" Porque no los dos? Both apply (and more!) :)
    – Jan
    Commented Jul 5, 2015 at 6:42
  • @JoshRibakoff added my comments and a bit more clarification in the answer.
    – Jan
    Commented Jul 5, 2015 at 15:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.