0

When describing DOM trees, most sources I found online describe the DOM tree as consisting of nodes.

I found this incredibly confusing, as I thought the DOM tree was actually just a tree of JS objects built into the Browser Runtime Environment.

My questions are as follows:

  • Is the DOM tree really just consisting of ECMAScript objects?
  • How are these objects connected to create the tree? E.g., is there a children property on each?
  • Is Node an actual object, to which other objects are prototype linked? For example, an element in a HTML document is represented in the DOM tree as an instance of the HTMLElement constructor function (const foo = new HTMLElement()), which in turn is [[prototype]]-linked to Element.prototype, which in turn is [[prototype]]-linked to Node.protoype?
Improve this question
22
  • 3
    Exactly what sort of objects DOM nodes are is not part of the spec. They might be JavaScript objects, but in other environments they might be something else. All the spec stipulates is that they work as documented.
    – Pointy
    Commented Jan 3, 2023 at 23:01
  • 3
    The DOM tree has bindings for ECMAScript (and Java) but is not per se a set of ECMAScript objects.
    – DeeGee
    Commented Jan 3, 2023 at 23:12
  • 1
    @DeeGee perhaps you could add an answer describing how the DOM tree built by a browser differs from, and relates to, the apparent tree of JS objects available in a JS script in a HTML document? Does the browser maintain two separate trees, or how does it work under the hood?
    – Magnus
    Commented Jan 3, 2023 at 23:18
  • 1
    I thought I'd find a dupe but it takes more time than expected and I don't have enough to compose an answer either, but some initial readings: chromium.googlesource.com/chromium/src/+/master/third_party/… and doc.servo.org/script/dom
    – Kaiido
    Commented Jan 3, 2023 at 23:49
  • 1
    The JavaScript runtime has an "external" layer that something like a browser can use to introduce objects that are visible "inside" the runtime, but which are in fact (for example) C++ objects. The (now removed) Java ScriptEngine mechanism had something similar, so that Java objects could be visible to JavaScript code launched from Java.
    – Pointy
    Commented Jan 3, 2023 at 23:54

1 Answer 1

Reset to default
3

Is the DOM tree really just consisting of ECMAScript objects?

No. The Document Object Model describes generic objects, specifying how their attributes and methods model a document. It does not say anything about how those objects are constructed or what language they are implemented in. You'll find DOM implementations written in C++, Rust, Java, JavaScript, and probably more.

How are these objects connected to create the tree? E.g., is there a children property on each?

Not all objects in the DOM are tree nodes, but for those that are, yes: childNodes and parentNode form a tree. The nodeName, nodeValue and attributes model the contents of the tree.

Is Node an actual object, to which other objects are prototype linked?

Yes, the ECMAScript bindings for the DOM (via WebIDL) stipulate that nodes are represented as ECMAScript objects with a prototype inheritance chain for interfaces like Node.

I thought the DOM tree was actually just a tree of JS objects built into the Browser Runtime Environment.

They might be native JS objects, but most commonly they are host objects that wrap/proxy the builtin DOM implementation of the browser. The wrappers are often constructed on the spot by getters only when they are accessed, not already created when the page is loaded.

Improve this answer
9
  • Thank you, Bergi, as clear as always. The Web IDL was fantastic, it answered a lot of my questions. Quick follow-up questions: 1) Are platform objects and interface objects (both defined in the Web IDL) the same? 2) Could you perhaps add information on how exactly the browser knows which DOM node an interface object (which is always a built-in function object) corresponds to? 3) When you say wrapper, what do they wrap / how does it work?
    – Magnus
    Commented Jan 4, 2023 at 17:00
  • One additional follow-up: Do you know when exactly DOM objects are created and added to the global object, by the browser runtime environment? The ECMAScript spec defines the point in time when the global object is created (i.e. when the host realm is initialized), however, it does not specify when non-standard built-in objects (like the document object) are created and added to the global object.
    – Magnus
    Commented Jan 4, 2023 at 17:15
  • I found the answer to my last question above. If others are interested in when initial objects, including interface objects based on interfaces defined in Web APIs, are added as properties to the global object, it happens in step 11 of InitializeHostDefinedRealm ( ), right after the global object has been created and the standard built-in objects have been added: tc39.es/ecma262/#sec-initializehostdefinedrealm
    – Magnus
    Commented Jan 4, 2023 at 17:35
  • 1
    No, platform objects are not the same as interface objects. An interface object is an object representing the interface itself (not a particular instance), like HTMLElement, Node, EventTarget etc. An interface object has an interface prototype object, like HTMLElement.prototype, Node.prototype etc. These are initialised with the realm.
    – Bergi
    Commented Jan 4, 2023 at 17:37
  • 1
    Platform objects on the other hand are the actual instances, like the global document or the result of createElement(). They are created when needed.
    – Bergi
    Commented Jan 4, 2023 at 17:38

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