Jan Mikoláš
Glossary
DOM
The DOM is the document tree inside the browser. It gives JavaScript a way to find the correct element, respond to an event and safely change a specific part of the interface without turning it into an uncontrolled mix of HTML strings.
Short definition
A tree of nodes between an HTML document and an interactive interface.
When loading HTML, a browser creates an object model of the document. It contains the document, elements, text nodes and attributes arranged into parent, child and sibling relationships. To a script, a button, heading or paragraph element is therefore not merely text but a specific node whose content, attributes and events can be read or changed in a controlled way.
The DOM is neither the HTML source file nor a visual snapshot of the page. The browser repairs some incomplete structures according to HTML parser rules, and JavaScript can subsequently add, remove or rearrange the tree. CSS determines how these elements are rendered, and visual order can differ from DOM order. A DOM change also does not save itself to a database or send data to the server.
The problem it solves
It enables precise and controlled interaction with a page
The DOM gives an application a model on which it can change interface state, handle a form or respond to API data.
- finding a specific button, form field or information area
- responding to a click, value change, form submission or keyboard event
- safely setting the text, attribute and state of an existing element
- adding or removing a cart item, validation error or loading state
- work performed by a frontend framework that usually coordinates DOM changes from its own state
Practical example
Updating product availability without inserting untrusted HTML
After a button is clicked, a script loads the inventory state from an API. It selects an existing element through a data attribute and updates its text. The server response is not treated as ready-made HTML, so its text cannot create a new script or unexpected element in the document through this step.
The example addresses only the client-side display. The API must validate data, and the application must separately decide who may view or change inventory information. A real application should also provide a loading state, timeout and clear error state.
JavaScript
const button = document.querySelector('[data-stock-check]');
const result = document.querySelector('[data-stock-result]');
button?.addEventListener('click', async () => {
const response = await fetch('/api/products/123/availability');
if (!response.ok) throw new Error('Dostupnost nelze načíst.');
const data = await response.json();
result.textContent = data.inStock ? 'Skladem' : 'Momentálně není skladem';
});How it works
From HTML to a safe change to a specific node
Text diagram: HTML → browser parser → DOM tree → event and JavaScript → element change → new rendering.
- The browser parses HTML It creates a document with a tree of nodes from the response. Parser rules can alter the result compared with invalid or incomplete source markup.
- Relationships form in the tree Elements have parents, children and siblings; text and attributes are also part of the document model.
- JavaScript selects a target A selector or stored reference finds a specific element. The selector should express meaning rather than an accidental visual position.
- An event or data changes state A handler can set text, a field value, a safe attribute or a class corresponding to the interface state.
- The browser updates the display It recalculates the required parts of rendering from the DOM and CSS. The change remains local until the application explicitly sends data to the server.
Important considerations
Nodes, events and state have their own responsibilities.
Understanding the tree helps create simpler, more accessible interactions than manually assembling large blocks of HTML.
Elements, text and attributes
An element represents button or p, for example, a text node its content and an attribute a property such as aria-expanded or disabled. Every change should respect the element meaning.
Parents, children and siblings
The tree structure determines where an element lives. It helps select the right target and explains why an event can propagate through ancestors.
Events
A click, form submission or field change can trigger a handler. A correct design also considers the keyboard, focus and native default behaviour.
DOM and rendering
The CSSOM and other internal structures contribute to the final display. An off-screen or visually reordered element may remain in the DOM and accessibility tree.
Safe APIs
textContent is suitable for ordinary text, attributes require their specific safe method, and permitted HTML needs deliberate sanitisation. An unverified string must not be interpreted as HTML by default.
Benefits and limitations
Direct work with the interface requires discipline.
Benefits
- precise, incremental changes to part of a page without a full reload
- native events, forms and focus available across browsers
- a tree structure that supports semantic HTML and accessibility
- the ability to respond to network data and display loading or error states
Risks and common mistakes
- inserting an untrusted string as HTML and introducing XSS
- changing large parts of the tree too often and damaging performance and focus stability
- using visual order as a substitute for logical document order
- treating a client-side change as confirmed server storage
- forgetting that a hidden element can still affect assistive technologies or the tab order
When to work with the DOM
When an interaction adds value to a functional HTML foundation.
Direct DOM work makes sense for small interactions: expanding guidance, safely updating availability, managing focus in a dialog or displaying a validation error. Large applications can use a framework that organises DOM updates for developers. Even then, developers need to understand the real tree, events and semantics of the resulting HTML.
Not every state requires JavaScript. Navigation and form submission often have a natural HTML and HTTP path. An interface is more resilient when it can complete the basic task even if the script fails and uses JavaScript as an enhancement rather than a reason for content or controls to disappear.
What to consider
Change the specific element, preserve meaning and do not transfer trust from the client.
Safe and accessible DOM work is part of ordinary frontend design.
- start with semantic HTML and native controls rather than clickable imitations
- use safe text APIs for text data and clearly defined sanitisation for permitted HTML
- after a change, verify focus, keyboard navigation, error announcements and control states
- limit the scope of changes and measure performance for long lists or frequent updates
- send permanent changes to the server and handle the response so the UI does not pretend they succeeded
Common questions
The DOM without common misconceptions
Is the DOM the same as HTML?
No. HTML is the transferred document, while the DOM is an object tree created by the browser. The parser and JavaScript can cause the DOM to differ from the original source.
Does changing the DOM save data to the database?
No. It changes only the current browser state. A permanent change requires a server request and successful server-side processing.
Why not insert API text as HTML?
If data is not strictly controlled and safely sanitised, interpreting it as HTML can execute or insert unexpected content. Setting text content is safer for ordinary text.
Is the DOM only for JavaScript?
The DOM is the standard object model for a browser document, and JavaScript is the most common language web applications use to work with it. Accessible HTML and CSS remain important without custom scripts.
How I build user interfaces in practice
I build interactions on semantic HTML and a secure connection with the API.
When developing applications, I address client-side state together with accessibility, failure scenarios and backend data checks.