Document Object Model
The live tree of objects a browser builds from a document, and the surface every UI framework writes to.
The Document Object Model is the in-memory tree a browser constructs from an HTML document, exposed to scripts as objects that can be read and mutated. Changing it changes what is rendered. Every user-interface framework on the web is ultimately a strategy for producing DOM mutations.
Three characteristics drive most practical difficulty.
It is stateful in ways the source does not describe. Focus, selection, scroll position, form values, and media playback live in the DOM, not in the markup that produced it. Replacing a subtree destroys all of them, which is why remounting a component silently loses the caret or the scroll offset.
Reading it can be expensive. Geometry queries force the browser to complete pending layout work, so interleaving reads and writes produces layout thrashing.
Text has more than one representation. The property giving rendered text differs from the one giving raw content: a field displayed in uppercase by a style rule reads back as uppercase through one and in its authored case through the other. Saving the wrong one silently rewrites data — see contenteditable.
Frameworks that keep a virtual model of the tree add a fourth: the framework's picture and the real tree can diverge, and any mutation made outside the framework's knowledge will be diffed against a stale model. See Hydration.
See also4
Hand-picked in the note itself — the neighbours worth reading next.
Semantic HTML
Using elements for their meaning, so the document conveys structure without extra description.
Design & Interface12 connections
Portal
Rendering an element into a different part of the document than its logical parent.
Web Platform14 connections
Accessibility
Designing so that people with disabilities can use a thing, and the standards that make it checkable.
Design & Interface20 connections
Focus Management
Deliberately controlling which element receives keyboard focus as an interface changes.
Design & Interface14 connections
Related3
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from11
Notes elsewhere in the wiki that reach for this one.
- AccessibilityDesign & Interface
Designing so that people with disabilities can use a thing, and the standards that make it checkable.
- ARIADesign & Interface
Attributes that describe roles, states, and relationships to assistive technology when HTML cannot.
- contenteditableWeb Platform
The HTML attribute that makes an element directly editable, and the surface behind most rich-text editors.
- Focus ManagementDesign & Interface
Deliberately controlling which element receives keyboard focus as an interface changes.
- Focus TrapDesign & Interface
Confining keyboard focus inside a modal surface so it cannot wander behind it.
- HydrationWeb Platform
Attaching client-side behaviour to server-rendered markup without rebuilding it.
- Keyboard NavigationDesign & Interface
Making every interactive affordance reachable and operable without a pointer.
- PortalWeb Platform
Rendering an element into a different part of the document than its logical parent.
- Progressive EnhancementWeb Platform
Building so the core experience works without scripts, with richer behaviour layered on top.
- Semantic HTMLDesign & Interface
Using elements for their meaning, so the document conveys structure without extra description.
- Stacking ContextDesign & Interface
The nested coordinate system that decides what paints above what, and why z-index often does nothing.