DOM and events

23 Dec

TL;DR.

This lecture provides a detailed exploration of JavaScript's Document Object Model (DOM) and event handling techniques. It is designed for web developers seeking to enhance their skills in creating dynamic and interactive web applications.

Main Points.

DOM Basics:
- Understanding the structure and significance of the DOM.
- Methods for selecting elements effectively and safely.
- Creating and updating nodes using best practices.
Event Handling:
- Exploring event bubbling and capturing mechanisms.
- Implementing event delegation for dynamic content management.
- Accessibility-friendly event patterns to enhance usability.
Performance Considerations:
- Importance of efficient DOM manipulation to improve user experience.
- Avoiding repetitive queries to enhance performance.
- Best practices for secure and efficient event handling.

Conclusion.

Mastering the DOM and event handling is essential for web developers aiming to create responsive and user-friendly applications. By implementing the techniques and best practices outlined in this article, developers can enhance their skills and improve the overall performance and accessibility of their web projects.

Key takeaways.

Understanding the DOM is crucial for web development.
Effective element selection methods enhance code reliability.
Creating nodes safely prevents security vulnerabilities.
Event delegation simplifies event management for dynamic content.
Accessibility considerations improve user experience for all users.
Performance in DOM manipulation is key to responsive applications.
Using data attributes can stabilise element selection.
Implementing best practices for event handling is essential.
Regular accessibility testing ensures compliance and usability.
Minimising reflows through efficient updates enhances performance.

Understanding the Document Object Model (DOM).

The Document Object Model (DOM) is the browser’s in-memory representation of a web page. Instead of treating a page as “just HTML”, the browser converts that HTML into a structured object graph that JavaScript can read and change. This structure is commonly described as a tree: the document sits at the root, and each element, attribute, and piece of text becomes a node connected through parent-child relationships.

That tree-like structure is what makes interactivity possible. When a product page updates a basket total, when a SaaS dashboard expands a panel, or when a cookie banner disappears after consent, the browser is not rewriting the entire page from scratch. It is updating specific nodes in the DOM. This is why DOM literacy matters to founders and teams shipping quickly: once the DOM is understood, small targeted changes become easier, safer, and faster to implement across platforms such as Squarespace, custom apps, or embedded tools.

Conceptually, the DOM sits between three moving parts: HTML provides the initial structure, CSS provides styling rules, and JavaScript applies behaviour. When JavaScript modifies the DOM, it may also trigger the browser to recalculate styles and layout. Those recalculations are not “bad”, but they are expensive when done repeatedly or unnecessarily. Many performance issues that show up as “the page feels slow” are actually “the DOM is being manipulated in a costly pattern”.

Learn methods for selecting elements effectively.

Element selection is where most DOM work begins. A script cannot update a menu, validate a form, or insert a banner until it can reliably find the correct node. JavaScript offers multiple selection APIs because each one targets a slightly different use case: speed, convenience, compatibility, or returning a single element versus a collection.

The common methods below are still worth understanding because they appear in legacy scripts, tutorials, and no-code platform snippets. The practical difference is not just syntax. It is what type of collection is returned, whether the result is live or static, and how predictable the behaviour is when the DOM changes after selection.

document.getElementById(id): Retrieves one element by its unique ID. It returns either that element or null. It is fast, explicit, and ideal for stable page anchors like a primary navigation wrapper or a fixed modal container.
document.getElementsByClassName(className): Returns a live HTMLCollection of elements that share a class. “Live” means it updates automatically if matching elements are added or removed later, which can be helpful or surprising depending on the pattern used.
document.getElementsByTagName(tagName): Returns a live HTMLCollection of elements by tag (such as “a” or “section”). It is broad and can be useful for sweeping operations like adding rel attributes to outbound links.
document.querySelector(selector): Returns the first element that matches a CSS selector. This is often the most readable approach for modern scripts because it mirrors how elements are targeted in CSS.
document.querySelectorAll(selector): Returns a static NodeList of all matches for a CSS selector. “Static” means it does not automatically update if the DOM changes after selection.

The reason querySelector-style APIs dominate modern snippets is flexibility. They support attribute selectors, combinators, and pseudo-classes. That means a script can target something like the first primary button inside the hero section or every input that is required without needing extra IDs or custom markup. For instance, selecting a button with a specific data attribute can be as precise as a CSS rule, which is useful when working inside constraints such as templated Squarespace blocks where IDs may be inconsistent across pages.

Understanding querySelector vs querySelectorAll.

The distinction between querySelector and querySelectorAll is not cosmetic. It affects control flow, error handling, and performance. querySelector returns one element (the first match in document order), while querySelectorAll returns a list-like collection of all matches.

That difference matters in everyday patterns. A script that expects one element (a single modal, a single header, a single cookie banner) should usually use querySelector so it can fail fast and predictably when the element is missing. A script that is meant to apply behaviour across many items (pricing cards, FAQ accordions, multiple CTAs) should use querySelectorAll and iterate.

There is also a subtle operational difference: querySelectorAll returns a static snapshot. If new matching nodes are inserted later, they will not appear in the previously returned NodeList. That is often the safer default because it prevents “moving targets” during iteration. If a script needs to respond to DOM changes over time, it can intentionally re-query, or for more advanced cases, employ a MutationObserver to watch for specific additions. The key is intentionality: scripts should either work on a snapshot, or explicitly opt into reacting to changes, rather than accidentally doing both.

Explore safe practices for creating and updating nodes.

Creating and updating nodes is where functional code can turn into fragile code if it leans on shortcuts. The safest baseline approach is to construct elements via document.createElement, set properties explicitly, and then insert them into the DOM using append or related methods. This approach reduces security exposure, improves maintainability, and makes it easier to reason about what the browser will render.

A common shortcut is using innerHTML to inject markup. innerHTML is not inherently “evil”, but it increases risk when any part of the string comes from user input, URL parameters, third-party feeds, or external CMS content. The core issue is cross-site scripting (XSS): if untrusted content is treated as HTML, a malicious payload can be executed in the user’s browser. For teams moving fast, this is a frequent source of avoidable security incidents, especially when scripts are pasted into platforms that encourage quick embed patterns.

createElement-based construction helps because text is treated as text when assigned with textContent, and attributes are set with defined APIs rather than raw string interpolation. This becomes particularly valuable when building UI elements like alerts, banners, or inline validation messages. Even if the content comes from a CMS, it can be inserted as text safely and then styled via classes, reducing the chance of a hidden script sneaking into the page.

Performance also benefits from disciplined DOM updates. Browsers may perform reflow and repaint operations when layout-affecting changes occur. Updating the DOM in a tight loop, especially while reading layout measurements like offsetHeight or getBoundingClientRect between writes, can trigger layout thrashing. A robust habit is to group reads together, group writes together, and insert completed fragments in one operation when possible.

Append patterns: append, prepend, insertAdjacentElement.

Once a node exists, insertion method choice influences clarity and performance. Classic methods like appendChild() remain valid, but modern DOM APIs have expanded the toolset. The goal is predictable placement with minimal layout churn.

appendChild(): Appends a node as the last child of a parent. It moves the node if it already exists elsewhere, which is handy for reordering but can surprise scripts that expect cloning behaviour.
insertBefore(): Inserts a node before an existing child. This is useful when adding a banner above the first item in a list, or inserting a new row in a specific table position.
insertAdjacentElement(position, element): Inserts relative to a reference element using positions such as beforebegin, afterbegin, beforeend, afterend. This is often more readable when a node needs to sit beside another node rather than inside it.

In practice, insertAdjacentElement is valuable for platform work where markup is locked down. For example, if a Squarespace template wraps content in generated containers, inserting “afterend” of a known block can be more stable than trying to append inside a container that may change between template versions.

For bulk operations, a DocumentFragment can reduce overhead by allowing multiple nodes to be assembled off-DOM and then inserted once. That reduces repeated reflow. The principle is simple: build first, attach once. It is a small change that can noticeably improve perceived speed on pages with many repeated components such as product grids or content directories.

Familiarise with attributes and dataset usage in the DOM.

Attributes are the values written in HTML markup, while properties are the JavaScript-facing representations on the element object. Sometimes they map directly, sometimes they do not. Understanding that relationship helps avoid bugs where code “sets the attribute” but the browser UI does not update as expected, or where a property change does not persist in the markup.

For standard element fields, direct property assignment is typically clearer and can be more efficient. Setting element.id, element.href, element.value, or element.className is straightforward and communicates intent. setAttribute still has a place, especially for non-standard attributes, SVG quirks, or when an attribute name does not correspond cleanly to a property. The decision should be driven by correctness first, then clarity.

Class handling is a frequent example. className overwrites the entire class string, which is fine when the script “owns” the element’s classes, but risky when other parts of the system also use classes for styling and state. In those cases, classList is safer because it adds and removes specific tokens. That matters in real-world websites where marketing teams use classes for styling while developers use classes for behaviour toggles.

Understanding dataset: always strings; convert when needed.

The dataset API exposes custom data-* attributes as a convenient object. It is a practical bridge between markup and behaviour: designers or content editors can place data-* values in HTML, and scripts can read those values without hard-coding logic. This is especially useful in component-like patterns, such as defining animation speed, tracking IDs, or feature flags per element.

dataset values are always strings, even when they “look like” numbers or booleans. That means conversion is not optional when numerical operations are involved. A value of "10" concatenates if treated as a string, while 10 behaves as expected in arithmetic. parseInt and parseFloat handle basic conversion, while Number can be used for stricter casting if the input is guaranteed to be numeric.

Conversion also needs defensive thinking. If a data attribute is missing, dataset returns undefined. If it is present but empty, it returns an empty string. Code that relies on dataset should handle these edge cases explicitly, especially on pages where a marketing edit could remove an attribute unintentionally. A stable pattern is: read the value, validate it, fall back to a default, then proceed. That one habit prevents a surprising amount of front-end breakage in production.

Once the DOM selection, safe node creation, and attribute handling basics are locked in, the next step is applying them to real interaction patterns such as event handling, state management, and performance-aware rendering.

Selecting elements.

Understanding how to select elements inside the DOM (Document Object Model) sits at the centre of everyday front-end work. Every interaction, toggling a menu, validating a form, lazy-loading content, personalising a logged-in view, starts by locating the right node and then manipulating it predictably.

Element selection looks simple until a site grows: multiple templates, reused components, A and B tests, translated pages, and changing layouts. At that stage, careless selectors quietly become a source of bugs, performance issues, and “it worked yesterday” regressions. Strong selection habits keep scripts stable even when a Squarespace layout changes, when a Knack view re-renders, or when an ops team updates content without a developer ticket.

Pick selectors that survive real-world change.

Differentiate between querySelector and querySelectorAll.

Both querySelector and querySelectorAll accept a CSS selector string, yet they return different shapes of data and encourage different patterns. Choosing the wrong one usually does not fail loudly, it fails subtly: a click handler attaches to only one button, a set of cards is only half initialised, or a script runs but updates the wrong element.

querySelector returns the first matching element (or null if nothing matches). It is ideal when a page should only have one instance: a primary navigation container, a modal root, a search field, or a single “Add to basket” button in a specific component.

querySelectorAll returns a static NodeList of all matching elements. “Static” matters: it is a snapshot at the time of the call. If a script later inserts new elements (common with filters, pagination, or CMS-driven blocks), those new nodes will not appear in an existing NodeList. In those scenarios, it can be safer to re-query, or to use event delegation (binding one listener to a parent and checking the target) rather than binding listeners to every item once.

Practical example: if a page has several buttons with the class .example, then document.querySelector('.example') targets only the first button. That can be correct for “the first featured card”, but wrong for “every card should animate on view”. The second case needs document.querySelectorAll('.example') followed by iteration such as forEach.

Edge case: some developers expect querySelectorAll to behave like older live collections such as those returned by getElementsByClassName. That mismatch can cause bugs when content is loaded dynamically. When a UI is built around repeated rendering, it is often better to treat selection as an operation that can be repeated safely, and to write idempotent initialisers (scripts that can run twice without doubling event listeners or duplicating DOM changes).

Use querySelector when the script intends to operate on one element only.
Use querySelectorAll when the script intends to operate on a set, and plan for dynamic content if the set may change.
When selecting many elements, consider whether one parent listener (event delegation) can replace multiple listeners for performance and maintainability.

Scope selections to avoid fragile global queries.

Global selectors that start at document work fine on small pages, but they tend to become brittle as a site evolves. Scoping means selecting a parent container first, then selecting within it. This pattern reduces accidental matches, increases readability, and typically improves runtime costs by shrinking the search area.

In practical terms, a scoped selector looks like: select the component root, then call the same selection methods on that root. For example, a “pricing card” script should not search the entire page for .button or .title. It should identify the card container and then look for its own internal elements. That way, if the page contains multiple pricing areas, each instance can initialise itself without interfering with the other.

Scoping also guards against common CMS realities. On Squarespace, blocks can be reordered and duplicated. On marketing sites, content teams may add a second newsletter form for a campaign. A global selector can suddenly hit the wrong element because “the first match” changed. A scoped selector stays anchored to the intended component.

Performance is not just about speed, it is also about predictable behaviour. When a selector accidentally matches more than intended, scripts may apply styles twice, attach duplicate listeners, or compute wrong values. Scoping reduces that risk by design.

Select a component root using a stable hook (often a data attribute), then query within it.
Avoid overly generic selectors such as .button at the document level.
Prefer “component-first” initialisation: find all component roots, then initialise each one locally.

Implement null checks for handling “element not found” scenarios.

Any selector can fail. A template may not include that element on every page, a feature flag might remove it, or content editors could delete a block. When code assumes a selection always succeeds, it risks runtime errors that break unrelated functionality.

A null check is a simple guard: if the selection returned nothing, the script stops gracefully. This is not defensive coding for the sake of it, it is operational resilience. It keeps a site stable when layouts change, when scripts are reused across multiple pages, or when an A and B test temporarily removes a section.

For example, selecting .my-element and then calling a method on it without checking can throw an exception and halt subsequent JavaScript execution. In many browsers, one uncaught error can prevent later scripts from running, which can impact tracking, form submission, navigation behaviours, and other critical flows.

Null checks become even more important in dynamic applications. If a filter panel only exists after a user logs in, or a modal is injected into the DOM on demand, the first selection attempt may legitimately return null. In those cases, scripts can wait for the element to appear (such as responding to a click event that creates it), or observe DOM changes via a mutation observer. The key is to treat “not found” as a normal state, not as a crash condition.

Guard single-element selections: if the element is missing, exit early.
Guard chained selections: check the parent exists before searching for children.
When code runs on multiple pages, assume some pages will not include the feature and code accordingly.

Use data attributes for stable element selection.

Classes and IDs often change for design reasons. A rebrand, a theme switch, or a new layout can rename or restructure CSS classes, even though the behaviour should remain the same. data attributes (the data-* family) provide behavioural hooks that can remain consistent regardless of styling.

A strong pattern is to treat classes as presentation and data attributes as intent. For example, a button might carry a styling class like .btn-primary (which design may rename), but a behavioural hook like data-action="subscribe" can remain stable. JavaScript then targets [data-action="subscribe"], leaving designers free to refactor the CSS without breaking the behaviour.

Data attributes also improve readability in complex pages. When debugging, it is often clearer to see data-modal="pricing" than to infer meaning from a class name that exists for layout purposes. This is especially helpful for teams where ops, marketing, and developers all touch the site. Behavioural hooks become self-documenting.

When using attribute selectors, quoting values is a safe default: [data-role="example"]. This avoids edge cases when values include special characters. It also encourages consistent conventions, such as kebab-case values, to keep selectors easy to scan and less error-prone.

Use data attributes as durable hooks for scripts and automation.
Keep the naming convention consistent across a project, such as data-role, data-action, and data-component.
Avoid encoding styling intent in data attributes; keep them behavioural and semantic.

Technical depth: selection strategy checklist.

Reliability, performance, and maintainability.

When a site scales, selection choices start to look like architecture decisions. A dependable strategy tends to follow a few repeatable rules: choose stable hooks, scope to the smallest sensible container, handle missing nodes gracefully, and design for repeated initialisation when the DOM changes.

Stability: prefer [data-*] selectors for behaviour and keep class selectors for styling.
Specificity: scope within a component root instead of selecting globally from the document.
Safety: apply null checks before reading properties or calling methods.
Dynamic content: assume content can re-render; avoid one-time NodeList assumptions in interactive UIs.
Observability: when something is not found, fail silently for users but consider logging in development to catch regressions early.

With these patterns in place, the next step is to connect selection to action: attaching event listeners, updating attributes, toggling classes, and coordinating UI state in a way that stays robust across devices and templates.

Creating and updating DOM nodes.

This section breaks down practical techniques for building and updating UI directly inside the DOM (Document Object Model). DOM manipulation sits at the centre of many real-world workflows, from small Squarespace enhancements to SaaS dashboards built with custom JavaScript. When it is done well, pages feel responsive and stable. When it is done poorly, teams end up battling sluggish performance, brittle UI behaviour, and security risks that can quietly undermine trust.

Most modern teams operate with a mix of constraints: founders want rapid iteration, ops teams need predictable maintenance, and developers need clear patterns that scale. The goal is not to memorise every method, but to understand why certain approaches are safer, faster, and easier to reason about under change. That mindset makes it simpler to troubleshoot issues like “buttons stop working after an update”, “the page freezes when filtering a table”, or “user content breaks layout”.

Safely create elements with document.createElement.

When building new interface pieces programmatically, document.createElement() is the most reliable baseline. It creates a real element node without requiring HTML parsing, which keeps behaviour predictable and reduces exposure to injection bugs. It also encourages a clearer separation between structure (elements), content (text), and behaviour (events), which becomes increasingly important as a UI grows.

At a practical level, this method suits any feature where content changes over time: search results, notifications, dynamic pricing blocks, cart indicators, FAQ expanders, and in-product banners. Instead of generating HTML as a string and asking the browser to interpret it, the script constructs nodes and sets only what is needed. That means fewer surprises when content contains special characters, and fewer hard-to-find layout issues when markup is malformed.

Creating an element is straightforward:

Example:

const newDiv = document.createElement('div');

After creation, attributes and content can be applied in a controlled way. For text, prefer textContent rather than injecting HTML. For classes, use classList to add or remove states cleanly. For accessibility, ensure role and label attributes are intentional, especially for interactive components that mimic buttons, tabs, or accordions.

Example of creating an element.

This example creates a new div, sets its content safely, then appends it into an existing container:

const container = document.getElementById('container');
const newDiv = document.createElement('div');
newDiv.textContent = 'Hello, World!';
container.appendChild(newDiv);

In production UI work, the same pattern scales into a “render function” that takes data and returns a node. That makes it easier to test and easier to update when design changes. It also helps avoid accidental coupling, such as building strings that depend on fragile whitespace or ordering rules.

Edge cases appear quickly in real apps. A few that commonly matter:

If the container might not exist (for example, the code runs on multiple pages), the script should guard against null before appending.
If content comes from a CMS, the script should assume unexpected characters and treat them as text by default.
If elements need events (click, change, input), attaching listeners at creation time tends to be simpler and more reliable than re-attaching after string-based DOM rewrites.

Understand the risks of using innerHTML.

innerHTML is tempting because it is fast to write and easy to visualise. It can also be the source of some of the most expensive bugs a team will ever debug. Two problems dominate: security exposure and performance overhead.

From a security standpoint, inserting unsanitised user-generated content through innerHTML can open the door to XSS (cross-site scripting). That risk is not limited to comment boxes and forms. It can surface anywhere content passes through systems: CMS fields, product descriptions, imported CSVs, support messages, marketplace integrations, and even URL parameters. If an attacker can inject a script tag or an event handler into HTML that is later rendered, the page can execute malicious code in the visitor’s browser. For e-commerce and SaaS, that can mean session theft, checkout manipulation, or silent tracking.

On performance, assigning innerHTML forces the browser to parse the entire HTML string and rebuild nodes. That has two side effects that catch teams off-guard:

Existing child nodes are destroyed and recreated, which can wipe transient state (input values, scroll position inside nested elements, focus state, and selected options).
Event listeners attached to replaced nodes are lost, so interactive elements can “randomly stop working” after a rerender unless listeners are reattached or event delegation is used.

There are still valid uses for innerHTML, but the situations are narrower than many projects assume. If the inserted HTML is fully trusted, comes from a controlled template, and the update frequency is low, innerHTML may be acceptable. When updates are frequent or content is not fully trusted, node-based construction is normally the safer default.

Best practices for innerHTML use.

Sanitise any content that did not originate from a trusted, controlled template. If sanitisation cannot be guaranteed, treat it as plain text instead of HTML.
Use textContent for plain text updates. It avoids HTML parsing and cannot execute scripts.
Prefer createElement plus appendChild for dynamic interfaces, especially for lists, results panels, and repeated components.
When HTML must be used, keep the inserted template small and stable, and avoid repeatedly rewriting the same container.

In operational terms, this reduces “support drag”. Fewer UI bugs mean fewer internal pings, fewer emergency fixes, and fewer strange customer reports that are difficult to reproduce.

Use append patterns for node insertion.

Once nodes exist, they need to be placed into the document. DOM insertion methods appear similar, but each has trade-offs that matter when building maintainable UI. Picking the right method improves readability and reduces accidental layout breakage.

The most common insertion tools are:

appendChild() adds a node as the last child of a parent.
insertBefore() inserts a node before a specified child, which is useful for ordered lists or “insert above” interactions.
insertAdjacentElement() inserts relative to an element’s position, often easier than climbing to a parent node.

Choosing between them often comes down to intent:

appendChild reads well when adding items to the end, such as chat messages, activity logs, and “load more” product cards.
insertBefore is clearer when order matters, such as inserting validation messages above a form field or adding pinned items at the top of a list.
insertAdjacentElement can be cleaner when the insertion point is “before this element” or “after this element” without manually referencing the parent.

This example inserts a new paragraph before an existing element:

const existingElement = document.getElementById('existing');

const newElement = document.createElement('p');

newElement.textContent = 'This is a new paragraph.';

existingElement.parentNode.insertBefore(newElement, existingElement);

Two implementation details are worth calling out for teams that ship frequent updates:

These methods move nodes if they already exist elsewhere. Appending the same node twice does not duplicate it; it relocates it. Duplication requires cloning.
Insertion can trigger layout recalculation, so doing many inserts one-by-one can become costly on larger pages.

For founders and SMB operators, this matters because “small UI tweaks” can unexpectedly raise maintenance costs. A simple banner or dynamic table can become slow at scale if it adds hundreds of nodes individually on every filter interaction.

Minimise reflows with DocumentFragment.

Performance issues in dynamic pages often trace back to repeated layout work. Every time nodes are inserted, moved, or styled, the browser may perform a reflow (layout calculation) and sometimes a repaint. The impact is not always visible on a developer’s laptop, but it shows up on mobile devices, older machines, and pages with heavy CSS or third-party scripts.

DocumentFragment is a simple pattern that reduces this cost by batching work off-screen. Elements are created and appended to the fragment first. Only once the fragment is complete is it appended to the live DOM. The browser then performs far fewer layout calculations compared to inserting each item directly.

The following pattern creates 10 list items, collects them in a fragment, then appends them once:

const fragment = document.createDocumentFragment();
for (let i = 0; i <10; i++) { 
const newItem = document.createElement('li');
newItem.textContent = 'Item ' + (i + 1);
fragment.appendChild(newItem);
}
const list = document.getElementById('myList');
list.appendChild(fragment);

This technique becomes especially valuable when dealing with:

Rendering search results, filters, or collections from larger datasets.
Building complex UI blocks like cards that contain headings, meta text, buttons, and tags.
Updating multiple parts of a component in response to one user action, such as sorting a table and updating its summary counts.

A useful mental model is that DocumentFragment behaves like a staging area. It is not visible on its own, and it does not create a live layout cost until it is appended. For teams building on platforms such as Squarespace with injected JavaScript enhancements, it can noticeably reduce “jank” during interactions like expanding accordions, switching tabs, or loading product lists.

From here, the next step is understanding how to update existing nodes without tearing down entire sections, and how to manage events and state so UI remains consistent as content changes.

Attributes and dataset usage.

Understanding how to work with DOM attributes and datasets is a foundational skill for modern web development because it affects correctness, performance, maintainability, and how well front end code integrates with tools and platforms. In practical terms, teams often need to attach metadata to HTML, read it reliably in JavaScript, and keep behaviour predictable across browsers, frameworks, and content management systems.

This section breaks down how attribute APIs differ from direct property assignment, why dataset values behave the way they do, and how data attributes can act as a pragmatic configuration layer for UI components. It also covers naming conventions that reduce bugs when projects scale, especially when multiple developers, marketing teams, or no-code operators touch the same templates.

Compare attribute methods and properties.

When code reads or writes values on an element, it usually chooses between attribute methods such as getAttribute() and setAttribute(), or direct property assignment such as element.id, element.className, or img.src. Both routes can work, but they solve slightly different problems, and mixing them without a clear mental model often leads to subtle defects.

An attribute is the value stored in the HTML markup (or in the element’s attribute map). A property is a JavaScript-facing interface exposed by the browser’s element object. Frequently, a property reflects an attribute, but not always in a one-to-one way. Some properties are computed, normalised, or even mapped to multiple underlying attributes. Understanding this distinction matters when building dynamic interfaces that rely on state, such as filters, accordions, pricing toggles, and onboarding flows.

When getAttribute/setAttribute is the better fit.

Attribute methods are often the safer choice when working with custom attributes and when the code needs exact string values as written in markup. This includes data-* attributes, accessibility attributes (such as aria-*), and attributes that are not exposed as convenient properties on the element.

For example, if an element has data-user-id="123", reading it with element.getAttribute('data-user-id') returns exactly what the DOM has stored for that attribute: a string or null. That predictability is useful in defensive code paths where “missing value” and “empty string” must be handled differently. It is also helpful when parsing server-rendered HTML where attributes may appear or disappear depending on page templates.

Attribute methods also matter when setting values that are not represented as standard properties. If a team decides to attach data-experiment-group="B" to run A/B behaviour toggles, the most portable and explicit approach is often setAttribute, since it mirrors how the value is stored and inspected in markup.

Another practical case appears when integrating with platforms like Squarespace, where templates and blocks may generate HTML with attributes that scripts read later. When markup is the source of truth, attribute methods align with that reality and reduce surprises from property normalisation.

When direct property assignment wins.

Direct property assignment tends to be clearer and faster for common, well-supported element features. Setting img.src = 'image.jpg' is typically simpler than writing img.setAttribute('src', 'image.jpg'), and it also communicates intent: the code is altering the runtime state of an image element, not just editing a text token in markup.

Properties can also provide processed values that are more useful than raw attributes. A classic example is a link’s href. Reading a.getAttribute('href') returns what is written in markup, which might be a relative path like /pricing. Reading a.href typically returns a fully resolved absolute URL. Both are correct, but each is correct for different jobs. If a script needs to compare links across environments (staging vs production), resolved URLs can reduce edge cases. If a script needs to preserve the original relative path for output or templating, the attribute form is more appropriate.

Boolean behaviour is another area where properties are often more intuitive. Certain HTML attributes behave like on/off flags. Using the property can make the code read closer to the intent, while using attributes can require remembering special rules. For example, “present vs absent” is commonly the real meaning in markup, while properties can present a true/false view.

Practical decision rules for real projects.

On production sites, the decision is rarely ideological. Teams benefit from a small set of rules that keep code consistent. A workable approach is:

Prefer properties for standard element capabilities (id, value, checked, src, href, disabled) where the browser offers a clear, supported API.
Prefer attribute methods for custom metadata, for exact markup inspection, and for attributes without reliable property equivalents.
When reading values, decide whether the code needs the raw markup value (attribute) or the browser-normalised runtime value (property), then commit to that choice consistently.

This consistency becomes increasingly important as scripts grow, especially when multiple scripts interact with the same elements. If one component writes an attribute while another reads a property, the system can become difficult to reason about, even when it “usually works”.

Recognise dataset values are strings.

The dataset API is a convenient way to access data-* attributes, but it comes with a major constraint: values are always strings. If code assigns element.dataset.value = 42, the stored value becomes '42'. This is not a bug; it reflects how HTML attributes work. Attributes are text, and dataset is a friendly wrapper around that text.

That behaviour impacts logic in subtle ways. String arithmetic leads to concatenation rather than numerical addition, and comparisons can become lexicographic. For example, '10'> '2' is true in a string comparison, which can break sorting and thresholds if a script forgets to convert types.

Type conversion patterns that stay safe.

When a dataset value represents a number, explicit conversion is the responsible choice. For integers, parseInt() can work if paired with a radix argument (commonly 10). For decimal numbers, parseFloat() is typical. In strict logic, conversion should also handle invalid values without throwing the UI into a broken state.

A robust pattern is to treat dataset values as untrusted input, even if the team “controls the markup”. Markup often becomes editable in CMS contexts, A/B testing tools, translations, or quick marketing edits. A single stray character can turn '30' into '30px', and conversion will behave differently depending on the parser. Defensive checks protect runtime behaviour.

If the code expects an integer, it can convert then validate: number is not NaN, number is finite, number is within expected bounds.
If the code expects a boolean, it can define an explicit mapping such as 'true' and 'false', rather than relying on truthy or falsy string behaviour.
If the code expects structured data, it can store JSON in the attribute and parse it, but only when the complexity is genuinely needed.

Edge cases that commonly trip teams.

Several dataset edge cases appear regularly in production:

Empty attribute values such as data-mode="" still return an empty string, which might be treated as “configured” even though it carries no meaning.
Missing attributes behave differently depending on access method. With dataset, a missing key generally returns undefined, while getAttribute returns null.
Whitespace and casing can leak into values, especially when attributes are edited manually. Normalising via trimming can prevent silent mismatches.
Localisation can alter number formats. If content editors insert 1,5 instead of 1.5, parseFloat will stop at the comma. In such cases, teams should define allowed formats and enforce them in templates.

Teams that build reusable components on top of dataset often end up writing a small parsing layer. That layer acts as a contract: dataset stays human-editable, while the component receives typed inputs that match its expectations.

Use data attributes for configuration.

Data attributes offer a low-friction way to attach configuration to HTML elements without inventing extra classes or ids purely for scripting. This is especially useful when the HTML is generated by a CMS, a no-code builder, or a shared component library, where keeping markup readable matters as much as keeping JavaScript clean.

In practice, data attributes function as a small, declarative interface between markup and behaviour. A button with data-action set to submit, open-modal, or add-to-cart can map to behaviour in a single event handler. This pattern scales well because it centralises logic while keeping per-element differences visible in the HTML.

Good use cases for data attributes.

Data attributes work best when they represent stable configuration rather than rapidly changing application state. Practical examples include:

UI toggles: data-expanded="false" to initialise a collapsible panel.
Analytics hooks: data-event="pricing_cta_click" to label events without coupling to CSS selectors.
Feature flags: data-feature="beta" to selectively enable enhancements.
Component parameters: data-max-items="6" to cap rendered items in a list.

These patterns help teams avoid “selector soup”, where scripts depend on brittle class combinations that are later changed for styling. By separating style classes from behaviour configuration, teams reduce the risk that a visual redesign breaks core functionality.

Keep the configuration layer lightweight.

Data attributes are not a replacement for application state management. When a page needs complex, frequently updated state, pushing everything into data-* can become messy and hard to debug. A useful guideline is that data attributes should describe initial conditions and stable settings, while runtime state should live in JavaScript variables, component instances, or a state store.

Another practical constraint is that data attributes are exposed in the DOM. That visibility is useful for debugging, but it also means sensitive information should never be stored there. User tokens, private IDs that unlock access, or internal pricing logic should be kept server-side or in protected client storage patterns, not in HTML attributes where anyone can inspect them.

When teams use platforms like Knack, Replit, or automation tools such as Make.com, data attributes often become the glue between rendered templates and scripts that enhance interactivity. Treating them as configuration keeps those integrations maintainable and reduces the need for brittle, platform-specific hacks.

Maintain consistent dataset naming.

Consistent naming conventions for dataset keys reduce friction in every stage of development: implementation, debugging, onboarding new team members, and maintaining components over time. In HTML, the convention is kebab-case such as data-user-id. In JavaScript, dataset converts that into camelCase such as element.dataset.userId.

This mapping is simple, but inconsistency in naming quickly creates mistakes that look like logic bugs. A team might write data-userID in markup, then attempt to read dataset.userId and get undefined. The problem is not the code’s logic; it is a naming mismatch.

A naming scheme that scales.

A maintainable naming scheme tends to share these characteristics:

Use kebab-case in markup (data-payment-method, data-plan-tier).
Prefer nouns for values and verbs for actions (data-action="open", data-target-id="modal-1").
Keep keys specific enough to avoid collisions in large pages (data-gallery-max-items rather than data-max).
Document expected values and types in the component code, so a future editor knows whether a value expects a number, boolean, or enum-like string.

In collaborative environments, this becomes a contract between the people who write templates and the people who write scripts. Clear naming reduces the need for comments, and it lowers the risk that a quick content update breaks interactivity.

Operational benefits for founders and teams.

From an operational perspective, predictable dataset naming makes websites easier to manage without developer intervention. Marketing or ops teams can update attributes to change behaviour while staying inside guardrails defined by developers. That is one of the simplest routes to cost-effective scaling: the UI remains configurable, while the underlying code remains stable.

As projects grow, this discipline also supports better testing. Automated tests and QA scripts can target explicit data attributes rather than brittle CSS selectors, which improves test reliability during redesigns. It also supports clearer analytics tagging, since event labels can be tied to a known data-event vocabulary rather than inferred from the DOM structure.

With attributes, properties, and dataset patterns clarified, the next step is to connect these concepts to real component design, where parsing, validation, and predictable conventions turn simple data-* values into reliable behaviour across larger interfaces.

Understanding the role of DOM events.

DOM events sit at the centre of how the web feels interactive rather than static. They are signals emitted by the browser when something meaningful happens in the page, such as a user clicking, scrolling, typing, focusing a field, submitting a form, resizing a window, or a resource finishing loading. When these signals fire, JavaScript can respond by running a function, commonly called an event handler, to update the interface, validate data, trigger an animation, or call an API.

In practical terms, events are the bridge between what a person does and what the application does next. A checkout button would not do anything without a click event. A search bar would not offer suggestions without input events. A modal would not close when pressing Escape without keyboard events. Even “passive” behaviours such as tracking engagement, measuring conversions, or improving onboarding depend on reliable event handling.

For founders and small teams, event literacy is not only a developer concern. It affects product analytics, conversion optimisation, accessibility, and performance. A Squarespace site with custom code injection, for example, often relies on events to enhance navigation, add micro-interactions, or improve user experience without replacing the whole theme. The same thinking applies in web apps built on platforms such as Knack or custom tooling where user actions should trigger workflows or automations.

There are three important layers to keep in mind when thinking about events:

What happened: the event type, such as click, submit, input, keydown, change, focus, or load.
Where it happened: the element that originated the event and the path the event travels through.
What should happen next: the handler logic, including UI updates, data validation, navigation changes, or external requests.

That “where it happened” piece is where event flow becomes the difference between clean, scalable implementations and brittle code that breaks when layouts change.

Event flow: capture, target, bubble.

Event flow describes how an event moves through the document when it fires. This matters because the handler does not always run only on the element that was clicked. Instead, the event can be observed at multiple points in the DOM tree, which is why the same click may trigger multiple listeners if they exist on ancestors.

The browser models most events using three stages:

Capturing phase: the event travels from the document root down through ancestors towards the target element.
Target phase: the event reaches the element that actually initiated it.
Bubbling phase: the event then travels back up from the target through its ancestors to the root.

This behaviour is not a “quirk”; it is a deliberate design that enables patterns such as event delegation, centralised tracking, and layered UI behaviours. Consider a card component inside a grid: the card might have a click behaviour, the grid might implement selection or filtering logic, and the page might implement analytics tracking. With capturing and bubbling, each layer can listen without tightly coupling everything together.

There are also edge cases that impact implementation decisions:

Not every event type bubbles. For example, some focus-related events behave differently, and developers often use alternatives such as focusin/focusout when bubbling behaviour is needed.
Some events fire extremely frequently, such as mousemove or scroll, which means poor handler design can cause UI jank and battery drain. These usually require throttling/debouncing strategies rather than “just add a listener”.
Touch and pointer inputs can generate different event types depending on the device. Modern implementations often use pointer events to unify mouse, touch, and pen interactions.

When teams experience odd behaviour such as “the click handler runs twice” or “the parent handler triggers when it should not”, event flow is usually the root cause. It is also why deliberate decisions about where listeners are attached can influence maintainability and performance.

Event propagation direction.

During propagation, the capturing phase happens first, which means a parent element can “see” the event before the target element processes it. After the event reaches the target, bubbling starts, giving parents another chance to react as the event travels back up the tree. This is the foundation for event delegation, where one listener on a stable ancestor handles interactions for many child elements.

Delegation is especially valuable in real products where the DOM changes frequently. Examples include:

A product listing where filters replace the list items dynamically.
A dashboard table where rows are added, removed, or reordered after a database update.
A CMS-driven page where the same component pattern repeats across many sections.

Without delegation, every new child element needs a new listener, and every removed element risks leaving behind orphaned logic. With delegation, the parent listener remains constant. The handler inspects the event to determine which child was actually interacted with, then runs the correct action. This reduces listener count, simplifies teardown, and tends to be more resilient when layout changes.

Propagation control is also part of the toolbox. Handlers can stop the event from travelling further when it makes sense, such as when clicking a “delete” icon inside a clickable card should not also trigger navigation. That said, using propagation-stopping everywhere often hides architectural issues, so it should be treated as a surgical fix rather than a default pattern.

Distinguishing between target and currentTarget.

Effective event handling depends on reading the event object correctly. Two properties that are often confused are event.target and event.currentTarget. They can point to different elements, and that difference becomes critical once delegation is in play.

event.target is the element where the event originated. This is often the deepest element actually clicked, such as an icon inside a button, a span inside a link, or an image inside a card.
event.currentTarget is the element whose listener is currently running. If a click listener is attached to a parent container, then currentTarget will refer to that container, even if a nested element triggered the click.

When an application needs to know “which specific item was clicked”, it usually uses target, sometimes combined with DOM traversal to find the nearest relevant ancestor. When it needs “the element that owns the listener and state”, it uses currentTarget. Confusing these is a common cause of bugs such as applying an active class to the wrong element or reading the wrong dataset attribute.

In UI systems, the practical impact is substantial:

In a menu, clicking on a child icon should still activate the menu item, not the icon node itself.
In an accordion, clicks inside the header should toggle the correct panel even if the user clicks on nested typography elements.
In analytics, tracking should record the meaningful component interaction rather than the incidental nested element.

Understanding this split allows developers to implement clear handler logic: treat the event source as data and treat the handler owner as the controller.

Practical implications.

A common pattern is attaching a click listener to a parent list, then using the event object to work out which list item fired the event. If the listener is attached to the parent ul, then currentTarget is the list itself, while target could be a nested element inside a list item. This is why robust delegation logic often checks whether the click originated within a relevant child, then resolves the correct element before acting.

This approach can improve performance and maintainability in several ways:

One listener manages many items, keeping memory usage lower.
Dynamically inserted items work without extra wiring.
Refactoring markup is safer because behaviour is anchored to a stable parent, not to a fragile set of children.

There is also a subtle but important business outcome: fewer event listeners usually means fewer unexpected interactions in production, which reduces the time spent debugging “random” UI behaviour that affects conversions and trust.

Common pitfalls in event listener management.

Event listeners are easy to add and surprisingly easy to misuse. One of the most frequent mistakes is unintentionally attaching the same listener multiple times. This tends to happen when code runs on each page transition, component re-render, modal open, or CMS refresh, and the setup logic does not guard against duplicates. The result is familiar: one click triggers two submissions, analytics fires twice, animations stack, and performance degrades.

Listener problems often appear in these real-world scenarios:

A marketing team adds a script via code injection, then later adds a similar script in a different area, producing duplicated tracking or UI behaviour.
A single-page app mounts components repeatedly, but the unmount step forgets to detach listeners.
A form validation module attaches new listeners each time a user returns to the step, multiplying handlers.

Another category of pitfall is attaching listeners too “deep” in the DOM, which can create maintenance headaches. For instance, binding behaviour to every single button individually can be acceptable for a small UI, but it becomes expensive when the UI grows, becomes dynamic, or has repeated patterns.

Memory leaks are also a concern, especially when long-lived objects retain references to DOM nodes through closures. In modern browsers, garbage collection is sophisticated, but developers can still create situations where nodes cannot be collected because references remain in handlers stored elsewhere. This matters in web apps used for long sessions, such as admin dashboards, CRMs, internal tools, and no-code front ends.

Best practices for listener management.

Listener management works best when it is treated as part of architecture rather than a small implementation detail. The following practices reduce bugs while keeping interfaces responsive and easier to evolve.

Use event delegation: Attach a single listener to a stable parent element and resolve child interactions through event inspection. This is particularly effective for lists, tables, menus, galleries, and any UI where children can change.
Remove unnecessary listeners: Detach listeners when features are disabled, components are removed, or pages transition. This is a key habit in component-based systems and long-lived dashboards.
Avoid inline event handlers: Inline attributes mix structure and behaviour, reduce reusability, and make auditing harder. Using script-based listeners keeps responsibilities separated and makes it easier to test and evolve.
Be deliberate with high-frequency events: For scroll, resize, and mousemove, avoid heavy logic inside handlers. Use throttling or debouncing patterns and keep DOM writes controlled.
Prefer stable handler references: When removing listeners, the same function reference must be used. Creating anonymous functions inline makes cleanup harder, so named functions or stored references improve lifecycle control.

When these practices are applied consistently, the codebase becomes easier to reason about: fewer hidden side-effects, less duplicate execution, and clearer ownership of UI behaviour. That sets up the next step, learning how to design event-driven interfaces that stay maintainable as features and traffic scale.

Event bubbling and capturing.

In modern front-end work, event propagation is one of the core mechanics that determines whether user interactions feel predictable or frustrating. Every click, keypress, scroll, drag, focus change, and touch gesture starts as an event on a specific element, then travels through the Document Object Model (DOM) in a defined sequence. When teams understand how that travel works, they can design interfaces that remain stable as pages grow, menus become nested, components are re-used, and content is injected dynamically.

This matters for founders and product teams because many real UX problems are not design issues at all. They are event issues: a dropdown that closes when it should not, a modal that refuses to close, an “Add to basket” button that triggers two actions, or a form that refreshes the page unexpectedly. Those issues become cost centres as support tickets, lost conversions, and time-consuming debugging. Tight event handling improves reliability, reduces regressions, and often lowers the amount of code needed to keep a UI maintainable.

Event bubbling explained.

Event bubbling describes what happens after an event fires on a target element: the event then travels upward through its ancestors, one DOM level at a time, until it reaches the document root. So if a user clicks a button inside a card, inside a grid, inside the page body, the same click is available to each of those ancestors in turn. Each ancestor can run its own listener if it has one for that event type.

That “upward travel” is the reason a single click can appear to trigger multiple behaviours. For example, a product card might be clickable to open a detail view, while a button inside the card adds the product to a basket. Without careful handling, the click on the button also bubbles to the card, and suddenly “Add to basket” also opens the product. The behaviour is not random; it is propagation doing exactly what it was designed to do.

In most browsers, bubbling is the default for common events such as click, which is why it is used heavily for scalable UI patterns. A parent element can listen once and react to interactions coming from many children, which is especially valuable when a list is dynamic (items added/removed without reloading the page). This technique is commonly called event delegation, and it is one of the simplest ways to reduce the number of listeners attached to the page, which can improve performance and code clarity.

Implications of event bubbling.

Bubbling is powerful, but it changes how teams should think about responsibility and boundaries in UI code. When many elements can “see” the same event, the design of selectors, conditional logic, and handler scope starts to matter as much as the handler itself. If a parent is delegating events, it should typically check what was clicked before running the heavy logic, otherwise every click inside that region may trigger expensive processing.

Common edge cases show up in real business interfaces:

Nested interactive elements: a clickable card containing links, buttons, toggles, and menus. Bubbling can cause “double actions” unless a clear rule exists for what wins.
Overlapping click zones: an element that visually looks separate may still be inside another clickable container, especially in responsive layouts.
Dynamically injected content: when items are rendered after page load (AJAX or client-side rendering), delegation on a stable parent can be more reliable than binding listeners to each new item.
Analytics and tracking: a global click tracker can unintentionally capture sensitive interactions or skew metrics unless it filters events carefully.

Operationally, bubbling can lead to cleaner and faster code when it is used deliberately. The key is treating propagation as a feature, then designing handlers with explicit intent: which ancestor is allowed to react, and under what conditions.

Understanding stopPropagation.

Sometimes a UI needs an inner interaction to remain local. That is where stopPropagation() comes in. Called on the event object, it halts the event’s journey to ancestor elements. In plain terms, the event still happened, but higher-level listeners do not get a chance to respond to it.

This is useful when the nested interaction is the “final authority” on that action. A common example is a button inside a form section that should open a tooltip, expand advanced options, or copy text, without triggering outer click-to-close behaviour. Another frequent case is a modal window: the overlay area often closes the modal when clicked, but clicks inside the modal panel itself should not bubble to the overlay listener. A typical solution is to attach an overlay click listener that closes, and then call stopPropagation on clicks within the modal content container.

Propagation control is a UI safety valve.

It also helps prevent interactions from interfering with delegated handlers higher up. If a parent container uses delegation to interpret clicks across many children, stopPropagation can isolate a specific widget whose clicks should never be interpreted as navigation or selection changes.

When to use stopPropagation.

stopPropagation is best treated as a targeted tool, not a default habit. Overuse can make a codebase feel “haunted” because events stop reaching places that other developers expect. That increases debugging time, especially when multiple components are composed together and each tries to manage event flow differently.

Practical guidance that keeps teams out of trouble:

Prefer precise conditions over blanket stopping: often a parent handler can check event.target or use closest() to ignore clicks originating from certain UI controls, rather than blocking propagation entirely.
Use it at interaction boundaries: modals, dropdowns, popovers, and nested menus are typical boundaries where inner clicks should not escape.
Document intent in code: a short comment explaining why propagation must stop prevents future refactors from reintroducing bugs.
Test keyboard and accessibility interactions: stopping propagation on click does not automatically solve focus, keydown, or pointer events. Many UI bugs come from handling only clicks while keyboard interactions bubble differently.

From a technical perspective, it also helps to remember that stopPropagation affects propagation, not default browser behaviour. Preventing a form submit or link navigation is a separate concern handled by preventDefault.

Event capturing and its priority.

Event capturing is the other direction of travel. Instead of starting at the target and moving up, the event begins at the top of the DOM (window/document) and travels down towards the target. Listeners registered for the capturing phase run before bubbling listeners, which means capturing can intercept an event early.

Capturing is not usually enabled by accident. It is activated when a listener is registered with the capture option set to true (for example, in addEventListener). Teams often avoid it until they have a reason, but it becomes valuable when they need to enforce global rules. Capturing can be thought of as a “pre-flight check” layer: something runs before the event reaches the component that was clicked.

Knowing the difference between the phases becomes essential in complex UIs where multiple systems run on the same page. Marketing scripts, analytics trackers, accessibility layers, and UI component libraries can all bind to the same events. When something misbehaves, understanding whether a listener runs in capture or bubble often explains the ordering and the conflict.

Practical applications of event capturing.

Capturing is often helpful when the UI needs to detect interactions outside a component. A modal or dropdown commonly needs to close when a click happens anywhere else on the page. Bubbling can work for this, but capturing is sometimes more reliable when other elements stop propagation in the bubbling phase. By observing the click during capture, the “outside click” logic can run before a nested widget blocks the event.

Capturing is also relevant for:

Security and input sanitisation patterns: intercepting potentially risky interactions early, particularly in internal tools where user-generated content may produce unusual DOM structures.
Global keyboard shortcuts: catching key presses before a focused input consumes them, while still allowing opt-out rules for text fields.
Cross-component coordination: establishing consistent “close all popovers” behaviour across a page with multiple independent widgets.

Capturing should still be used carefully. Because it runs early, it can create surprising side effects if it modifies state in ways that downstream handlers do not expect. The best implementations keep capture handlers lightweight and focused on detection rather than heavy business logic.

Using preventDefault for forms and links.

preventDefault() stops the browser from performing its built-in action for an event. This is not about the event travelling through the DOM; it is about the browser’s default behaviour. For forms, the default action of a submit is typically a page navigation (refresh or redirect). For links, the default action is navigating to the href. For drag-and-drop, the browser may open a file. For key presses, the browser may scroll or submit depending on context.

Preventing the default is crucial in web applications that use custom submission flows. A form might validate fields, save state via an API, display inline errors, and only navigate after a server response. Without preventDefault, the browser may refresh immediately, wiping state and interrupting asynchronous logic. That can surface as “the form is broken” even though the validation and network code is fine.

For teams building on platforms such as Squarespace, preventDefault often appears in small enhancements: custom newsletter forms, gated download flows, or interactions where a link should behave like a button that opens a modal instead of leaving the page. The same principle applies in app-like front ends built in frameworks; even when a router handles navigation, developers often still prevent default link behaviour to keep transitions inside the single-page application model.

Best practices for using preventDefault.

Preventing default actions changes user expectations, so the replacement behaviour must be clear and accessible. If a form does not submit in the traditional sense, the interface should explain what happened and what is required next. If a link no longer navigates, the element should still behave like an interactive control with correct focus and keyboard support.

Always provide feedback: show validation messages, loading states, and confirmation text so users know their action registered.
Keep semantics aligned: if an element behaves like a button, consider using a real button for accessibility, rather than turning a link into a pseudo-button with JavaScript.
Handle failure paths: if an AJAX submit fails, preserve inputs and present a recovery step, rather than silently blocking submission.
Do not block without replacement: preventDefault should almost always be paired with an intentional alternative action, otherwise the UI feels unresponsive.

In technical debugging, it also helps to separate concerns: if a click triggers the wrong handler, that is often propagation (bubbling/capturing). If a click triggers the right handler but the browser still navigates or refreshes, that is usually missing preventDefault.

Once bubbling, capturing, stopPropagation, and preventDefault are understood as separate levers, teams can build interaction rules that scale cleanly as the interface grows. The next step is usually applying these ideas to real patterns such as event delegation, component isolation, and handling dynamic DOM updates without attaching a forest of listeners.

Delegation patterns.

Event delegation is a JavaScript pattern that reduces event-handling overhead by listening once on a parent element and reacting to interactions that occur on its children. Rather than wiring click handlers to every button, card, row, or link, a single listener can be attached to a stable container and rely on bubbling to capture interactions as they happen. This becomes especially valuable when a UI frequently changes, such as lists that re-render, product cards that load via pagination, or admin tables that add rows on the fly.

For founders and small teams shipping fast, delegation is less about clever code and more about operational reliability. Fewer listeners often means fewer memory leaks, fewer re-bind bugs after DOM updates, and fewer “it works until the next release” regressions. In practical terms, it helps a Squarespace site with injected scripts remain stable after layout tweaks, and it helps a Knack front end remain responsive even when records, views, or filters refresh content dynamically.

At a technical level, delegation leans on the browser’s event propagation model. Many events bubble from the originating node up through ancestors until they reach the root. A delegated listener sits at a convenient ancestor and inspects what actually happened. When implemented cleanly, this delivers a predictable and maintainable interaction layer, even as new nodes appear or old nodes disappear.

Implement event delegation for dynamic content management.

A delegated setup places one listener on a parent container that is expected to exist for the lifetime of the page or component. When a child is clicked (or otherwise interacted with), the event bubbles to the parent, where the handler decides whether that interaction matters. This approach avoids the common trap where new elements are appended to the DOM but do not work because their handlers were never bound.

A classic example is a list where each item has a “Remove” button. With direct binding, every new list item needs its own listener, and every time the list is re-rendered the code must re-bind everything. With delegation, the list container owns the event handling. New items automatically “work” because the listener already exists higher up. This is also effective for grids of cards, dropdown menu items, modals rendered late, or any UI produced by templates and asynchronous calls.

Delegation also improves performance characteristics that matter on real-world sites. A hundred listeners are not always disastrous, but they are needless overhead, particularly on mobile devices, low-powered laptops, or pages that already run analytics, chat widgets, and tracking scripts. One listener with a small routing function typically wins. It also reduces the surface area for bugs such as accidental double-binding (a common issue when an initialisation function runs more than once).

In practice, the delegated handler usually follows a simple sequence: capture the event, determine whether it originated from a relevant element, select the matching actionable element, then run the correct behaviour. This effectively creates a small interaction “router” for a component.

Choose a stable parent container that will not be replaced during updates.
Listen for a suitable bubbling event (often click, but sometimes input, change, keydown, or submit depending on the UI).
Detect whether the interaction matches an allowed action.
Execute the action without relying on fragile DOM assumptions.

Some events do not bubble in older browser models, and some behaviours (such as focus handling) need special handling or alternative events. For modern browsers, most interaction events needed for typical product and content sites can be delegated, though it is still worth verifying bubbling behaviour for the specific event type before building a pattern around it.

Use closest() to identify the intended clickable element.

Delegation introduces one recurring challenge: the element that receives the click is not always the element that should trigger the action. The event.target is the deepest element that was clicked, which might be an icon inside a button, an em tag inside a link, or an image inside a card. If the handler checks the wrong node, it may miss valid interactions or trigger the wrong behaviour.

The closest() method solves this neatly by walking up the DOM tree from the original target until it finds an ancestor that matches a selector. Instead of asking “what was clicked?”, the handler asks “what actionable element contains what was clicked?”. This produces far more resilient click logic, especially in real interfaces where interactive elements often contain nested markup for styling.

Consider a card layout where clicking anywhere on a card opens a detail view, but clicking a nested “Save” icon toggles a bookmark state. Using closest allows the handler to distinguish between a click inside the save control and a click on the rest of the card. The handler can first check for the most specific action (the save control), and only if it does not match, fall back to the broader action (open details). That ordering matters, because it prevents multiple actions from firing from a single click.

There are a few practical edge cases worth handling explicitly:

If closest() returns null, the click did not occur within a relevant control, so the handler should exit quickly.
If the actionable element is outside the delegated container (such as a portal-rendered modal), delegation on the container will not see it; the listener must be placed higher or on a different container.
If the UI uses Shadow DOM (less common in typical CMS contexts), event retargeting can change how targets appear; delegated patterns may need adaptation.

Used properly, closest becomes the core primitive that keeps delegated code readable. Instead of a chain of parentNode checks and class comparisons, the logic becomes a small set of selector matches that mirror the intent of the UI.

Ensure stable selectors for delegation using data attributes.

Delegated handlers depend on selectors to identify what should happen. If those selectors are fragile, the system breaks during routine design changes. Classes are frequently altered for styling, and IDs may be reused or removed during refactors. Stable selectors should reflect behaviour, not appearance.

Data attributes provide a strong approach because they can be reserved for behaviour. Attributes such as data-action, data-role, and data-id communicate intent directly. A designer can change class names for styling without touching the action system, and a developer can refactor HTML structure while keeping behavioural hooks intact.

A practical pattern is to treat data-action as the routing key and keep the delegated handler as a dispatcher. For example, a list container could handle actions like “remove-item”, “duplicate-item”, “toggle-details”, and “open-modal”. Each control declares its intent with data-action, and the handler maps those strings to functions. This scales well because adding a new control often means adding only one new function and one new mapping.

Data attributes also help in platform-heavy environments. In Squarespace, markup can be rearranged by changing sections, blocks, or templates. In Knack, view configurations can regenerate DOM structures. Behaviour-based attributes reduce the risk that minor platform-level changes invalidate selectors.

There are operational considerations as well:

Keep action names consistent and predictable (verb-noun is a common convention).
Avoid encoding styling meaning into data attributes; treat them as a behavioural API.
Use data-id or similar keys to connect DOM events to records, SKUs, or internal identifiers.
Validate and sanitise values before using them in network calls, navigation, or DOM insertion.

When teams treat the DOM as an interface boundary, data attributes become contracts. That mindset reduces regressions, makes QA simpler, and helps debugging because a quick inspect reveals what a control is supposed to do.

Handle nested interactive elements carefully to avoid conflicts.

Complex interfaces often contain interactive elements inside other interactive elements: a button inside a card that is clickable, a link inside a row with a row-level click, or a dropdown inside a modal that also listens for outside clicks. Without careful planning, one gesture can trigger multiple handlers and produce confusing behaviour.

The cleanest fix is usually structural and logical rather than heavy-handed propagation blocking. When designing delegated handlers, it helps to define priority rules and stop early. For example, if the click matches a specific control like a “Delete” button, the handler runs that action and returns immediately, preventing fall-through into the “open card” behaviour.

There are still cases where controlling propagation is justified. The event.stopPropagation() method prevents bubbling, and can be useful when a nested control should never trigger parent-level behaviour. The risk is that it can make behaviour harder to reason about when used broadly, particularly if multiple scripts expect bubbling to happen. Debugging then becomes a hunt for whichever handler stopped the event.

Another important tool is event.preventDefault(), which cancels the browser’s default action, such as following a link or submitting a form. This is often needed when turning a link-like element into a JavaScript-driven action, or when an action should only proceed after validation. PreventDefault and stopPropagation solve different problems, and mixing them without intent can create surprising UX issues, such as links that no longer work or forms that never submit.

Nested interactions also raise accessibility concerns. A button inside a link is invalid HTML, and can create keyboard navigation problems and inconsistent screen-reader output. A more robust approach is to avoid nesting interactive semantics where possible, and use layout techniques to achieve the same visuals. When nesting cannot be avoided due to legacy markup, the delegated handler should explicitly manage keyboard events (such as Enter and Space) so that behaviour remains consistent for non-mouse users.

Delegation works best when it is treated as a system rather than a trick: stable hooks, predictable routing, and clear priority rules. Once those fundamentals are in place, the next step is to connect delegation with broader UI patterns such as state management, progressive enhancement, and analytics-friendly interaction tracking.

Accessibility-friendly event patterns.

Ensure keyboard parity for interactions.

True accessibility starts when every interactive control behaves predictably without a mouse. Keyboard parity means the same outcomes are achievable whether someone clicks, taps, uses a trackpad, or navigates with keys. This is essential for people with mobility impairments, power users who prefer the keyboard, and users of assistive technology that simulates keyboard input. It also tends to improve overall product quality because it forces clearer interaction rules and fewer “hidden” behaviours.

In practice, the core expectation is simple: interactive elements should work with Enter and Space in a way that matches platform norms. Links activate with Enter. Buttons activate with Space (and typically Enter, depending on browser behaviour). When teams accidentally break this pattern, users can land on something that looks clickable but cannot be triggered, creating a dead end in the interface.

Keyboard parity is easiest when the UI uses native elements, because browsers already provide correct behaviour. The problems tend to appear when a non-interactive element is repurposed into an interactive one, such as a “button” built from a generic container. If a project must implement a custom interaction, the event handling should intentionally cover keyboard activation, pointer activation, and focus management as one coherent behaviour set rather than as separate afterthoughts.

A practical approach is to ensure that whichever handler performs the business action is shared across input methods. If a click triggers “open modal”, a key activation should call the same logic, not a second copy. This prevents divergence where keyboard users get slightly different outcomes (missing analytics events, skipping validation, failing to close overlays, and so on).

Common edge cases worth accounting for include:

Interactive elements inside overlays, menus, or dialogs where focus can be lost behind the overlay.
Controls that use only mousedown or mouseup and never listen for keyboard activation.
Components that block default keyboard behaviour by cancelling events without re-creating the intended interaction.
Elements that are visually clickable but not reachable because they are not in the tab order.

From a workflow perspective, teams often validate parity quickly by doing a “mouse unplug test”: attempt key-only navigation from the top of the page through every key interaction path. That simple routine reliably exposes broken triggers, missing focus states, and traps in complex layouts, particularly on marketing sites built with Squarespace where custom code injections can unintentionally interfere with base behaviours.

Prefer semantic HTML elements first.

Many accessibility issues are not caused by a lack of effort, but by starting from the wrong building blocks. Semantic HTML communicates meaning to browsers and assistive technologies in a way that custom scripting cannot fully replicate. When an interface uses a real button for an action and a real link for navigation, screen readers understand the role, browsers provide keyboard behaviour, and users receive consistent feedback without extra code.

Using native elements also improves maintainability. A UI built on correct semantics requires fewer event listeners, fewer ARIA fixes, and less conditional logic. It tends to be more resilient as the site evolves, because browser defaults continue to handle key behaviours like focus, activation, and disabled states. This matters for founders and small teams trying to scale content and UX without building a fragile, hard-to-debug front end.

One of the most common anti-patterns is styling a generic container to look like a button. Visually, it passes. Functionally, it fails: it may not be focusable, may not announce itself correctly to assistive tools, and may not support activation keys. A properly used <button> carries the correct role and keyboard behaviour by default, and it signals intent clearly to both humans and machines.

Semantic choices also help with SEO and analytics clarity because interaction intent is cleaner. For example, navigation actions remain links, making them easier to interpret in behaviour recordings, event tracking, and automated testing. On content-heavy sites, especially those publishing educational material, this reduces the chance of “mystery controls” that confuse crawlers and users alike.

When a design genuinely requires a custom widget, semantics still matter. The safest route is usually to start with a native element and enhance it, rather than starting with a generic element and attempting to recreate native behaviour. Even when a team adds ARIA roles later, that ARIA must reflect correct behaviour, which can be difficult to guarantee across all browsers and assistive technology combinations.

Practical guidelines that keep projects on track:

Use buttons for actions that change state or trigger behaviour.
Use links for navigation to another location or resource.
Ensure headings are true headings so assistive users can skim structure effectively.
Avoid making non-interactive elements interactive unless there is a strong reason and a full keyboard plan.

Manage focus states for keyboard navigation.

When a user relies on the keyboard, the interface needs to show where they are at all times. Focus state is the visible indicator that tracks the current target for activation. Without it, keyboard navigation becomes guesswork, which is especially punishing in dense layouts, multi-step forms, and e-commerce flows where users must confidently move between inputs and controls.

Browsers provide default focus outlines, but many designs remove them for aesthetic reasons. That removal often introduces a serious accessibility failure unless it is replaced with an equally visible alternative. A focus style does not have to be ugly or distracting, but it does need to be obvious against all background colours and across all interactive elements, including buttons, links, toggles, form fields, and custom controls.

Focus is not only a visual concern. It is also a behavioural contract. When an overlay opens, focus should move into it. When it closes, focus should return to the control that opened it. When a menu expands, users should be able to tab through menu items in a logical sequence. When a page updates dynamically, focus should not jump unexpectedly unless there is a deliberate reason aligned with user intent.

Teams often get better results by defining a focus policy early:

Which elements are tabbable, and in what order?
What is the expected focus destination after an action completes?
How are focus styles applied consistently across component types?
Which interactions must “trap” focus (such as dialogs), and how does escape work?

A frequent edge case appears in “infinite” pages or long marketing pages, where interactive components are injected or rearranged as the user scrolls. If the DOM changes without careful planning, the tab order can feel random, or focus can land on hidden elements. A simple guardrail is to ensure hidden content is not focusable, and newly revealed content becomes focusable only when visible and meaningful in the user’s current context.

Use ARIA for dynamic content properly.

Modern websites often update content without a full page refresh: dropdowns expand, tabs switch, accordions reveal sections, validation messages appear, and live notifications surface. Assistive technologies cannot reliably infer these changes unless the interface communicates them. ARIA helps bridge that gap by exposing state, relationships, and updates in a machine-readable way.

The key principle is that ARIA should describe reality, not wishful intent. If a menu is open, the state attribute should reflect open. If it is closed, it should reflect closed. If a control affects another region, the relationship should be explicit. This allows screen readers to announce changes and lets users build an accurate mental model of what is happening.

Two attributes commonly used in interactive UI are aria-expanded and aria-live. The first signals whether a collapsible control is currently open or shut. The second indicates that a region may change and should be announced. Used well, they prevent the experience where something changes visually but remains silent to a user who cannot see the screen.

ARIA becomes especially important when JavaScript handles state. If a dropdown is implemented with scripting, the code should update both the UI and the accessibility state in the same step. That means toggling classes and toggling ARIA attributes together, so assistive technology stays in sync. The same applies to validation errors: if an error message appears, it should be connected to the relevant input and announced at the right time, rather than being a silent block of text somewhere else on the page.

There are also failure modes teams should watch for:

Adding ARIA roles on top of native elements, which can reduce accessibility rather than improve it.
Using live regions for too much content, creating constant announcements that interrupt users.
Updating visual state but forgetting to update ARIA state, causing screen readers to report stale information.
Implementing custom widgets without defining keyboard patterns and state attributes together.

A reliable strategy is “native first, ARIA second”. When native elements already provide correct roles and behaviour, ARIA is often unnecessary. When a component is truly custom, ARIA can clarify state and updates, but it should be paired with correct keyboard support and focus management, otherwise it becomes a label on a broken interaction.

These event patterns set the groundwork for building interfaces that remain usable under real-world constraints, from keyboard-only navigation to dynamic content updates. With that foundation in place, the next step is usually to validate the patterns through testing workflows and component-level checklists, ensuring accessibility remains stable as the site or app scales.

Best practices and performance.

When working with the Document Object Model (DOM), practical decisions around performance and accessibility determine whether an interface feels “instant” or frustratingly slow. The DOM is not just a data structure, it is the live, interactive representation of a page. Every time code reads from it or writes to it, the browser may need to recalculate layout, repaint pixels, or re-run accessibility mapping.

For founders, product managers, and web leads, this matters because DOM-heavy pages often become the hidden cause behind poor conversion rates, weak SEO signals (such as elevated bounce), and spiralling support tickets about “the site being buggy”. For engineers, it is a reminder that clean code is not always efficient code, and small implementation details can create large costs at scale.

Why DOM performance matters.

DOM performance becomes a bottleneck when a site relies on frequent visual updates, large lists of elements, or complex layouts. Each “simple” change, such as setting text, toggling a class, inserting an element, can trigger the browser’s rendering pipeline. The expensive parts are typically layout calculations and paint operations, which can cascade across an entire page when changes affect geometry.

Two concepts tend to drive most slowdowns: reflow (also called layout) and repaint. Reflow happens when the browser recalculates where elements should sit and how large they are. Repaint happens when pixels are redrawn without changing layout, such as colour changes. If a script makes repeated DOM writes interleaved with reads, the browser may be forced into doing these recalculations over and over, which quickly adds latency.

In real projects this often appears in places like pricing tables that expand and collapse, filterable product grids, FAQ accordions, or dashboards built in tools such as Knack with embedded custom scripts. On lower-powered devices, or when a page has heavy third-party scripts, even small inefficiencies can turn interactions from “snappy” into “laggy”. That lag is not merely cosmetic; it changes user behaviour. People abandon checkout flows, stop exploring feature pages, and assume the brand is unreliable.

To reduce this cost, high-performing implementations typically separate “compute what should change” from “apply changes to the DOM”. They also aim to write to the DOM in batches and avoid touching layout-triggering properties during animation or rapid UI updates.

Reduce layout thrashing and repaints.

A common performance failure pattern is rapid, repeated DOM updates that force the browser to re-evaluate layout continuously. This can happen during loops, scroll handlers, resize handlers, and “live search” experiences. The practical goal is to minimise how often the browser is pushed into reflow and repaint work.

One of the safest strategies is to batch DOM mutations. Instead of inserting elements one-by-one into the live DOM, scripts can construct UI off-screen, then inject the result once. A useful tool for this is DocumentFragment, which lets a script build a set of nodes without triggering layout on every append. When the fragment is finally appended, the browser processes the change as a single operation.

Another effective pattern is to prefer class toggles over repeated inline style edits. Toggling one class can update many properties at once and keeps presentation in CSS where the browser is heavily optimised. This also improves maintainability, because marketing or design teams can change styling without requiring JavaScript rewrites.

It also helps to understand that some property reads trigger a “forced synchronous layout”. For example, reading dimensions (such as offset-based measurements) after writing to the DOM can cause the browser to immediately flush pending changes to compute accurate values. When this happens inside animations or frequent handlers, performance collapses. Strong implementations either avoid layout reads in hot paths or group all reads first, then all writes.

Avoid repeated queries in loops.

Repeated DOM queries inside loops are a classic source of slowdowns because they cause repeated traversal of the DOM tree. Even a selector that looks harmless can be expensive when executed hundreds or thousands of times, especially on pages with many nodes or complex selectors.

The stronger pattern is to query once, store references, then operate on the stored collection. Retrieving a set of elements with querySelectorAll and iterating the returned list is usually faster and clearer than repeatedly calling querySelector. This also reduces the risk of bugs where the loop is operating on a changing set of nodes after insertions or removals.

There are also subtle edge cases to consider. If a script queries a live collection (depending on the API used), the collection may update as the DOM changes, which can lead to skipped items or infinite loops when nodes are added while iterating. Using stable references and avoiding structural changes mid-iteration prevents those issues.

In dynamic interfaces, another approach is to anchor operations to a known container element rather than searching the entire document repeatedly. Scoped queries within a container reduce traversal work and reduce the chance of accidentally matching unintended nodes elsewhere on the page, which is particularly useful in CMS-driven layouts such as Squarespace where multiple blocks may share similar class names.

Use secure, efficient event handling.

Interactive sites depend on event handling, but naive implementations can silently increase memory usage, slow down interactions, and introduce brittle behaviour. The performance cost tends to appear when many elements each get their own listener, especially in lists that expand over time (product grids, search results, knowledge bases, comment threads, and so on).

A widely used strategy is event delegation. Instead of attaching listeners to every button, link, or list item, a single listener is attached to a stable parent container. Events bubble up, and the handler checks which child triggered it. This reduces the number of listeners in memory and ensures that newly added elements automatically work without re-binding listeners.

Delegation has a second advantage: it can simplify security and consistency. When logic passes through one handler, it is easier to centralise validation and guardrails, such as ensuring only expected targets trigger actions. This is relevant in environments where content blocks can be edited by non-developers, because a small markup change should not break event wiring across the site.

Methods such as stopPropagation and preventDefault should be treated as surgical tools rather than defaults. They can be necessary when building custom UI components (such as dropdowns, accordions, and modal flows), but overuse can break expected behaviour. A preventDefault on a link might block keyboard navigation patterns; a stopPropagation might prevent global handlers (such as “click outside to close”) from working correctly. When these methods are used, the logic should be explicit about why the default behaviour is being replaced, and alternative accessible behaviour should exist.

For heavy event streams, such as scroll, resize, pointermove, and input events, stronger implementations introduce rate limiting via debouncing or throttling. This avoids running DOM work hundreds of times per second. Even when the code itself is fast, the repeated layout and paint implications can make the experience feel unstable.

Test accessibility and real UX regularly.

Performance improvements are incomplete if the interface is not usable by people who rely on assistive technologies. Accessibility is both an ethical requirement and a practical business advantage because it expands reach, reduces friction, and tends to align with clearer UX patterns.

Accessibility testing should cover keyboard navigation, focus order, and visible focus states, not just automated checks. Components that work perfectly with a mouse can fail entirely when operated via keyboard. Regular audits should also check semantic structure: headings, button roles, form labels, and meaningful link text. Where semantics are insufficient, ARIA attributes can improve behaviour, but they work best as reinforcement, not as a substitute for proper HTML structure.

It is also worth testing against real user journeys rather than isolated components. For example, a form might be technically accessible but still frustrating if error messages are not announced clearly, if focus does not move to the error summary, or if validation triggers in an unpredictable way. These issues show up quickly when testing with screen readers and when observing users completing tasks end-to-end.

From a workflow perspective, teams often benefit from establishing a lightweight “definition of done” for interactive changes: confirm no major layout jank, confirm keyboard usability, confirm screen reader announcement for state changes, and confirm that interactions still behave correctly on mobile. Even simple habits like these prevent regressions that later become expensive to debug.

When these practices are applied together, the DOM stops being a source of random slowdowns and starts behaving like a predictable system. The next step is learning how to profile these issues using browser tooling, then turning the findings into measurable improvements that tie back to conversion, retention, and operational load.

Frequently Asked Questions.

What is the Document Object Model (DOM)?

The DOM is a programming interface for web documents that represents the structure of a document as a tree of objects, allowing developers to manipulate the content and structure dynamically.

How do I select elements in the DOM?

You can select elements using methods like getElementById, getElementsByClassName, and querySelector. Each method serves different purposes and offers various selection capabilities.

What are the risks of using innerHTML?

Using innerHTML can expose your application to security vulnerabilities such as cross-site scripting (XSS) and can lead to performance issues due to unnecessary reflows.

What is event delegation?

Event delegation is a technique where a single event listener is attached to a parent element to manage events for multiple child elements, improving performance and simplifying event management.

How can I ensure my web application is accessible?

To ensure accessibility, use semantic HTML elements, implement ARIA attributes, and provide keyboard navigation support, ensuring that all users can interact with your application effectively.

What is the difference between event bubbling and capturing?

Event bubbling occurs when an event propagates from the target element up to the root, while capturing starts from the root and goes down to the target element. Both methods allow for flexible event handling.

How do I improve performance in DOM manipulation?

To improve performance, avoid querying the DOM repeatedly in loops, use DocumentFragment for bulk updates, and minimise reflows by batching DOM manipulations.

What are data attributes used for?

Data attributes provide a way to store custom data directly in HTML elements, allowing for easy access and manipulation in JavaScript without cluttering the DOM with additional classes or IDs.

Why is keyboard parity important?

Keyboard parity ensures that all interactive elements can be operated using keyboard navigation, making your web application accessible to users with mobility impairments who may not use a mouse.

How can I test for accessibility compliance?

Regularly test your application using accessibility checkers, screen readers, and user feedback to ensure compliance with accessibility standards and improve usability for all users.

References

Thank you for taking the time to read this lecture. Hopefully, this has provided you with insight to assist your career or business.

Shift Asia. (2025, June 10). Understanding Javascript event propagation: Bubbling and Capturing. Shift Asia. https://shiftasia.com/community/javascript-how-event-bubbling-and-event-capturing-work/
Efkumah, E. (2023, May 15). How to master the DOM to build interactive web apps. DEV Community. https://dev.to/efkumah/how-to-build-dynamic-web-apps-by-mastering-the-document-object-model-dom-2mfm
Palmer, K. L. (2023, November 11). Is innerHTML really vulnerable? Medium. https://medium.com/@kimberlylpalmer/is-innerhtml-really-vulnerable-17d004defe74
MDN Web Docs. (2025, December 6). Document: querySelector() method - Web APIs. MDN. https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector
Cybrosys. (n.d.). JavaScript DOM (Document Object Model) cheatsheet. Cybrosys. https://www.cybrosys.com/blog/javascript-dom-document-object-model-cheatsheet
Educative.io. (n.d.). What are the different ways to select DOM elements in JavaScript? Educative.io. https://www.educative.io/answers/what-are-the-different-ways-to-select-dom-elements-in-javascript
AEL Data. (2023, June 22). JavaScript accessibility: Make your web pages more inclusive. AEL Data. https://aeldata.com/javascript-accessibility/
GeeksforGeeks. (2020, November 3). Event delegation in JavaScript. GeeksforGeeks. https://www.geeksforgeeks.org/javascript/event-delegation-in-javascript/
Jain, S. (2024, February 15). JavaScript in the Browser – How the Document Object Model (DOM) and Events Work. freeCodeCamp. https://www.freecodecamp.org/news/javascript-in-the-browser-dom-and-events/
Mozilla Developer Network. (n.d.). DOM events - Web APIs. MDN. https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Events

Key components mentioned

This lecture referenced a range of named technologies, systems, standards bodies, and platforms that collectively map how modern web experiences are built, delivered, measured, and governed. The list below is included as a transparency index of the specific items mentioned.

ProjektID solutions and learning: