The DOM's Inheritance Chain: EventTarget > Node > Element
Every HTML element is a stack of types: an EventTarget for events, a Node for tree structure, and an Element for common attributes. This lets you write type-safe DOM code, knowing a div has properties from all its ancestors.
Why it exists
The DOM is modeled as an object-oriented system to avoid reinventing functionality for every type of tag. Instead of each element type defining its own event system or tree-traversal logic, they inherit from a chain of common base classes. This makes the API consistent, predictable, and extensible.
The mental model
Every element in the DOM is an instance of a class that inherits from a series of more general classes. The core chain is EventTarget → Node → Element. An EventTarget can receive events and have listeners. A Node is an object in the document tree (with parents and children). An Element is a specific type of Node that can have attributes and is the base for all HTML, SVG, and MathML elements.
How it works
When you get a reference to an element, like an <input>, the object you receive is an instance of HTMLInputElement. Due to JavaScript's prototype chain, this object has access to all methods and properties from its entire inheritance line: HTMLInputElement, HTMLElement, Element, Node, and EventTarget. This is why you can call myInput.addEventListener(...) (from EventTarget) and access myInput.id (from Element) on the same object.
When to use it
You use this knowledge implicitly whenever you manipulate the DOM. In TypeScript, it's explicit. Understanding the hierarchy helps you know what properties are available on a given element type and why you might need to perform a type assertion. For example, the target of an event is an EventTarget, but you might need to cast it to an HTMLElement to check its dataset.
When not to use it
This hierarchy is not an optional pattern; it's the fundamental architecture of the DOM API. You don't choose whether to use it. Ignoring it by writing code that assumes properties exist on generic elements (e.g., event.target.value without checking the target type) leads to brittle code and runtime errors.
One canonical example
Consider const el = document.querySelector('.widget'). In TypeScript, el is typed as Element | null. You can safely access el.id or el.classList, as these are defined on the Element interface. However, if you try to access el.value, TypeScript will throw an error because not all elements have a value property. If you know .widget is an input, you must use a more specific selector or type assertion: const input = document.querySelector<HTMLInputElement>('.widget'). Now you can access input.value safely.
Interview question
What is the primary reason an HTMLInputElement object can both addEventListener() and access its id property?
- a.It inherits addEventListener from EventTarget and id from Element in its prototype chain.Correct
- b.HTMLInputElement is a composite object that aggregates features from various unrelated DOM interfaces.
- c.The DOM automatically injects these common methods and properties into all element objects.
- d.HTMLInputElement directly implements both functionalities for all input types.
Why? this is the answer
The card explains that an HTMLInputElement object gains addEventListener from its EventTarget ancestor and the id property from its Element ancestor through the inheritance chain. It does not directly implement or have these functionalities injected.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #dom
- #typescript
- #web-apis
- #inheritance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on dom — each one lists the topics its interview covers.
See open roles