DOM - freeCodeCamp.org

What is the Virtual DOM in React?

Matéu.sh — Wed, 05 Jun 2024 14:51:11 +0000

As web applications become more complex, managing updates to the user interface becomes a challenging task. This is where the Virtual DOM (Document Object Model) comes into play – particularly in React, the leading JavaScript library for building user interfaces.

The virtual DOM is a lightweight copy of the real DOM that allows React to manage changes more efficiently by minimizing the direct manipulation required on the real DOM. This process significantly enhances the performance of web apps.

Understanding the virtual DOM is essential for developers who want to get the best out of React. It plays a key role in how React updates the UI, ensuring that changes are applied quickly without unnecessary re-renders.

In this article, you'll learn:

What the virtual DOM is and how it works
How the virtual DOM compares to the real DOM
Benefits of using the virtual DOM
How React uses the virtual DOM
How the virtual DOM compares to the shadow DOM
Common misconceptions about the virtual DOM

What Is the Virtual DOM and How Does It Work?

The virtual DOM is an in-memory representation of the real DOM elements. Instead of interacting directly with the real DOM, which can be slow and costly in terms of performance, React creates a virtual representation of the UI components. This virtual representation is a lightweight JavaScript object that mirrors the structure of the real DOM.

Here's a step-by-step process of how the virtual DOM works:

Step 1 – Initial Rendering: when the app starts, the entire UI is represented as a Virtual DOM. React elements are created and rendered into the virtual structure.
Step 2 – State and Props Changes: as the states and props change in the app, React re-renders the affected components in the virtual DOM. These changes do not immediately impact the real DOM.
Step 3 – Comparison Using Diff Algorithm: React then uses a diffing algorithm to compare the current version of the Virtual DOM with the previous version. This process identifies the differences (or "diffs") between the two versions.
Step 4 – Reconciliation Process: based on the differences identified, React determines the most efficient way to update the real DOM. Only the parts of the real DOM that need to be updated are changed, rather than re-rendering the entire UI. This selective updating is quick and performant.
Step 5 – Update to the Real DOM: finally, React applies the necessary changes to the real DOM. This might involve adding, removing, or updating elements based on the differences detected in step 3.

For example, let's say we have the following counter functionality in the App component:

import React, { useState } from 'react';

function App() {
 const [count, setCount] = useState(0);

 return (
   <div>
     <h1>Counter: {count}h1>
     <button onClick={() => setCount(count + 1)}>Incrementbutton>
   div>
 );
}

export default App;

The virtual DOM representation will look like this:

{
 "type": "div",
 "props": {},
 "children": [
   {
     "type": "h1",
     "props": {},
     "children": [
       {
         "type": "TEXT_ELEMENT",
         "props": {
           "nodeValue": "Counter: 0"
         }
       }
     ]
   },
   {
     "type": "button",
     "props": {
       "onClick": "setCount(count + 1)"
     },
     "children": [
       {
         "type": "TEXT_ELEMENT",
         "props": {
           "nodeValue": "Increment"
         }
       }
     ]
   }
 ]
}

When the Increase button is clicked once, only the h1 element is changed:

{
 "type": "h1",
 "props": {},
 "children": [
   {
     "type": "TEXT_ELEMENT",
     "props": {
       "nodeValue": "Counter: 1"
     }
   }
 ]
}

Comparing the Virtual DOM to the Real DOM

To see the advantages of the virtual DOM, it's important to understand how it differs from the real DOM. The real DOM and the virtual DOM serve similar purposes but operate in distinct ways with significant implications for performance and efficiency.

The real DOM is a built-in standard interface in browsers that represents and interacts with HTML elements, from Doctype declaration and the root html element to every other element in it.

This real DOM represents the whole HTML document as a tree structure and allows JavaScript to manipulate and change HTML documents. Sometimes when those changes occur, the whole document might re-render.

This is in contrast to the virtual DOM, which uses a diff algorithm to compare the current and previous versions of updates to the DOM. It only re-renders the parts of the UI that have changed, instead of the whole thing.

Benefits of Using the Virtual DOM in Web Development

Simplified Development

The Virtual DOM lets you write code in a more declarative style. This means that instead of writing detailed instructions on how to update the UI, you can simply describe what the UI should look like, and React takes care of the rest. This is made possible by React's declarative syntax and its component-based architecture.

Improved Performance

One of the major advantages of using the virtual DOM is the significant performance improvement it offers. Direct manipulation of the real DOM is slow and can lead to performance issues, especially in complex applications.

Enhanced User Experience

The Virtual DOM contributes to a better UX by ensuring that UI updates are smooth, responsive, and without full-page refreshes. Users are less likely to experience lag or jank, resulting in a more seamless interaction with the app.

Cross-platform Development

The principles of the Virtual DOM are not limited to web development only. React Native – a version of React for building cross-platform mobile apps – uses a similar approach. This increases productivity and reduces development time because you can reuse code across web and mobile platforms

Common Misconceptions About the Virtual DOM

There are a few misconceptions about the virtual DOM. Let's look at five of these misconceptions and the realities of each of them.

The Virtual DOM Is a Browser Feature

Reality: the virtual DOM is an abstraction implemented by React, not a browser feature. Browsers have the real DOM, which is the standard way to represent and interact with HTML documents. The virtual DOM exists solely in memory within React and is used to optimize updates to the real DOM.

The Virtual DOM Replaces the Real DOM

Reality: The virtual DOM acts as an intermediary between React and the browser, not a replacement for the real DOM. The real DOM is still what the browser uses to render the UI, but the updates to it are managed through the Virtual DOM.

React is the Only Library and Framework that Uses the Virtual DOM

Reality: React only popularized the concept of the virtual DOM, it is not the only library or framework that uses it. Other frameworks like VueJS and SolidJS also use the virtual DOM to update the UI.

The Virtual DOM Solves All Performance Problems

Reality: The virtual DOM can significantly improve performance, but it is not a magical solution to all problems. Poor coding practices, unnecessary renders, and large component trees can still lead to performance issues.

The Virtual DOM and Shadow DOM Are the Same

Reality: The virtual DOM and shadow DOM are not the same thing. The virtual DOM is a lightweight copy of the Real DOM with which React optimize UI updates. On the other hand, shadow DOM is a browser technology used to encapsulate the styles and structure of web components.

Real DOM vs Virtual DOM vs Shadow DOM

Now that we've established that the virtual DOM, shadow DOM, and real DOM are not the same, let's look at the differences between the three of them.

Aspect	Real DOM	Virtual DOM	Shadow DOM
Definition	Standard browser API for representing and interacting with HTML documents	In-memory representation of the Real DOM	A browser technology that encapsulates and scopes DOM and style of web components
Flexibility	Directly manipulated via JavaScript or DOM APIs	Abstracted and optimized by the framework	Limited to component boundaries
Implementation	Provided by the browser	Implemented by frameworks like React and Vue	Part of the Web Components standard, provided by the browser
Performance	Direct manipulation can be slow and cause performance issues	Already optimized for efficient updates	Provides encapsulation, reducing style conflicts
Usage	For rendering and interacting with web documents	For efficient UI updates by frameworks	For creating isolated, reusable web components
Updates	Immediate updates to the UI	Updates are batched and optimized	Updates are scoped to the component, not affecting the global DOM
Repaints	Frequent updates can cause costly repaints	Minimizes repaints by batching updates	Scoped to the component, reducing global repaints
Use Cases	General web development and document manipulation	Efficient UI updates in frameworks like React and Vue	Encapsulation of styles and structure in web components

Conclusion

As you've read in this article, the Virtual DOM is a key React feature that enhances performance and efficient UI updates. With this, React can batch updates, minimize reflows and repaints, and apply changes efficiently. This makes UI updates fast and smooth, providing a better user experience in the process.

Understanding the Virtual DOM and how it works can help you build performant React applications.

Learn React and Next JS

Want to discover more cool React features like the virtual DOM? Enroll in my React 18 course on Udemy! I'll guide you through the React world by creating a cool 2048 game with animations from scratch.

JavaScript in the Browser – How the Document Object Model (DOM) and Events Work

Samyak Jain — Thu, 15 Feb 2024 20:07:14 +0000

In this in-depth tutorial, you'll learn all about the Document Object Model, or DOM for short. As a web developer, understanding the DOM is fundamental for interacting with web browsers and creating dynamic web applications.

Throughout this guide, we will explore the DOM's hierarchical tree structure, essential properties, and methods for accessing and modifying nodes. We'll also dive into event handling and various techniques for efficient DOM manipulation.

By the end of this guide, you should be able to confidently manipulate the DOM to meet the demands of your web development projects.

Prerequisites:

While this guide is designed to be beginner-friendly and accessible to anyone, having a basic understanding of JavaScript fundamentals will greatly enhance your ability to grasp the practical concepts covered.

Also, familiarity with HTML and CSS is a plus and will help you comprehend and apply the material we cover.

If you're new to JavaScript, consider familiarizing yourself with variables, data types, functions, loops, and basic DOM manipulation techniques before diving into this tutorial. This foundational knowledge will ensure a smoother learning experience as we explore more advanced topics related to the Document Object Model (DOM).

What is the Browser Object Model (BOM)?
What is the Document Object Model (DOM)?
DOM Tree Structure
– Types of Nodes in the DOM Tree
– Node Relationships
How to Work with DOM Elements
– Traversing the DOM
– Methods for Querying DOM Elements
– Specialized Selectors (Matches, Closest, Contains)
– How to Inspect DOM Elements
– Table Navigation in the DOM
How to Modify DOM Elements
– How to Manipulate Element Content and Visibility
– How to Modify Element Attributes
– HTML Insertion Methods
– How to Manipulate Classes with JavaScript
Event Handling in the DOM
– Common Types of Events
– Event Handlers
– Event Propagation
– Event Bubbling
– Event Delegation
Conclusion

What is the Browser Object Model (BOM)?

The Browser Object Model is like a set of tools provided by the browser itself. It's not part of the official DOM specification, but it's specific to web browsers. As a result, the objects and methods available in the BOM may vary between different browsers.

The BOM provides JavaScript access to browser-specific things like the browser's history, location, and browser window itself.

Window Object

The window Object serves as a global object in the browser, representing the browser window and is the top-level object in JavaScript when we're working in a web browser. You can access it by typing window in the browser console:

console.log(window); // prints the Window object

Since, it's global, you can access it from anywhere and use it to access other global objects such as the console and the alert function.

The window object is a key part of the BOM and provides access to many browser-related things. For example, window.location.href gives you the URL of the current web page.

Functions like alert(), prompt(), and confirm() are also part of the BOM, allowing you to interact with users through pop-up dialogs.

What is the Document Object Model (DOM)?

The Document Object Model (DOM) is a programming interface for web documents. It represents the structure of a web page, allowing interaction with its elements using programming languages like JavaScript.

The DOM contains the document object, which represents the DOM structure of the current web page and has properties and methods that allow you to manipulate the DOM.

You can access the document object by typing document in the browser console:

console.log(document); // prints the DOM object

You use document object to access and manipulate different parts of the HTML document. Elements within the DOM can be accessed using properties and methods of this object.

Examples include accessing the body or title element, retrieving HTML content (innerHTML), accessing text content (innerText) and changing styles.

// Accessing the document's title
console.log(document.title);

// Changing the document's title
document.title = "changed Title";

// Accessing the document's body 
console.log(document.body);

// Changing background color of body element using inline CSS
document.body.style.backgroundColor = "red";

You can use the DOM to interact with web pages dynamically. This allows JavaScript to access, modify, and manipulate the content, structure, and style of a web document in response to user actions or other events.

Let's illustrate the concept of DOM manipulation with a simple example:

<html>
  <body>
    <div id="container">
      <p id="message">Hello, World!p>
      <button id="changeText">Change Textbutton>
    div>

    <script>
      // we select the paragraph element by its ID
      let messageElement = document.getElementById("message");

      // let's add event listener to button element using ID
      document
        .getElementById("changeText")
        .addEventListener("click", function () {
          // this  will change the text content of the paragraph element
          messageElement.textContent = "Text Changed!";
        });
    script>
  body>
html>

In this example, we have an HTML document with a

container containing a

element and a <div id="myDiv" style="width: 200px; height: 200px; background-color: blue;">div> <button onclick="changeColor()">Change colorbutton>

When you load the HTML document in a web browser, you'll see the heading, two buttons, and a colored

element. Clicking the "Click me" button will trigger the showMessage function and display an alert.

Clicking the "Change color" button will trigger the changeColor function and change the background color of the

element to red.

As I'm sure you can guess, this barely scratches the surface on what you can do with DOM. Here's a longer list of DOM-friendly elements and methods and HTML attributes that you can also play with:

document.getElementById()
document.getElementsByClassName()
document.getElementsByTagName()
document.querySelector()
document.querySelectorAll()
innerHTML, setAttribute()
removeAttribute()
classList
classList.add()
classList.remove()
classList.toggle()
onClick
onMouseOver
onMouseOut

Wrapping Up

This was a brief introduction to DOM elements, where you caught a quick glimpse of the how and whys of controlling HTML elements. You also learned how you can add dynamic interactivity and fine-tuned programmatic versatility to your website.

This article comes from my Complete LPI Web Development Essentials Study Guide course. And there's much more technology goodness available at bootstrap-it.com

How the Z-index Property Works – Stacking Order of Elements in CSS

Franklin Okolie — Thu, 09 Feb 2023 22:48:03 +0000

If you're a front-end engineer, you've probably faced weird z-index bugs and ended up spending hours trying to fix them.

Change one property here and you have your header flying away from where it was meant to be.

Well, we can attribute this to the fact that debugging CSS can be quite hard and most times we are doing so blindly. We change properties expecting to see the bugs magically get resolved, but they don't.

Unlike JavaScript that yells at you, giving you hints about what you are doing, CSS is just watches you do rubbish and quietly hopes you figure it out.

One of the many ways to get really good at using CSS is by researching and understanding the mechanism behind some CSS properties you use every day.

This will give you a clear and concise technical know-how about how to implement certain complicated designs. It'll also give you insight on how to resolve some difficult unexplainable bugs you might come across while writing code.

The Problem with the Z-index Property in CSS

We can all agree that one of the weirdest, most confusing, and not-so-straightforward CSS properties is the z-index.

When I started learning CSS, I was told by certain instructors that you use z-index when you want a certain DOM (Document Object Model) element to be on top of another. Sounds simple, right?

So I thought – but life experience has a way of letting us know that things aren't always as easy as we thought they'd be.

Not understanding how the z-index property actually works behind the scenes led me down a frustating rabbit hole of having unexplainable bugs relating to z-index. So I started cranking up the z-index value to enormous numbers like the infamous 99999 to see if I could get the desired result.

Sometimes this works, but other times it doesn't which can be the most annoying thing because it worked the other time.

Another situation is when it works fine at first, but then as you progress in your work, you face yet again the same problem on a different part of your app. So this has you doing the default – cranking up the new z-index up to 99999999, an even bigger number than the previous one.

Deep down in your heart as a professional developer, you know this is not right. It is a mess (and personally, I hate messy CSS code). But you also know you have no idea how to approach the problem that will lead to a permanent fix and a win in your z-index wars.

If you are reading this article and want to understand the z-index once and for all, you're in the right place.

I'm about to help demistify the z-index for you. By the time you're done reading through this guide, I hope you'll know how to fix tough z-index bugs and how the z-index actually works. You'll also have a deeper and more fundamental understanding of how browsers render DOM elements and how it relates to the z-index.

Ready? Let's dive right in.

What is Stacking Context in CSS?

Before we even start to understand z-index in all its glory, it'll be to your benefit if you can, for a moment, pretend like you don't know anything about z-index. Forget what you know about it, because from here on, your mental model about z-index is about to change.

There is no smoke without fire, and the fire that powers the z-index property is a concept called stacking context. In the next section, we are going to go over the meaning of this term, what it actually means in practice, how it works, and how it relates to z-index.

The stacking context is simply a term we use to define how the browser decides which elements in the DOM come first and which to "render" on top.

When we start writing a block of HTML code, one element after the other, the natural way the browser decides which element comes on top is by checking the order of the DOM elements. See the codepen playground below for more details:

<div class="green-box">  div>
<div class="pink-box">  div>
<div class="blue-box">  div>

div{
  width: 100px;
  height: 100px;
  border: 3px solid;

}

.green-box{
  background-color: green;
}
.pink-box{
  background-color: hotpink;
  margin-top: -30px;
  margin-left: 20px;
}
.blue-box{
  background-color: blue;
  margin-top: -30px;
  margin-left: 40px;
}

From the example above, you can see how the browser stacks DOM elements. It does so by simply checking the DOM order of each element, and rendering the latter element on top of the former element.

Think of it this way – how do you stack books? The last one always appears on top, the first one is always the one at the bottom. When you see some stacked books, you already know that the one at the bottom of the stack was the first book to be added to the stack (it started the stack) and the one on the top of the stack was the last to be added to the stack.

In the example above, the blue box is on top because it is the last on the stack as interpreted by the browser, while the green box is at the bottom of the stack because it is the first element in the DOM order.

A pictorial representation of how the browser render DOM elements - shown as stacked books.

The process of the browser making the decision about which DOM element to be painted and rendered on top the other element is called the stacking context. Let's keep this in mind as we will make reference to this term during the rest of the article.

Whenever a stacking context gets created, it is a memo sent to the browser asking it to re-evaluate the DOM elements and render/stack them accordingly.

Now that we have seen and understood what a stacking context means and how the browser renders DOM elements, let's move to other CSS properties that have the ability to affect how the browser makes these decisions.

Positioned Elements in CSS

There is a rule of thumb I want you to always remember as you go about your daily battles with CSS, especially when working with z-index and the stacking context: "Positioned elements always come on top".

What does this mean? Let's find out below:

<div class="green-box">  div>
<div class="pink-box">  div>
<div class="blue-box">  div>

div{
  width: 100px;
  height: 100px;
  border: 3px solid;

}

.green-box{
  background-color: green;
  position: relative;
}
.pink-box{
  background-color: hotpink;
  margin-top: -30px;
  margin-left: 20px;
}
.blue-box{
  background-color: blue;
  margin-top: -30px;
  margin-left: 40px;

}

Here it goes! What happened? In the previous Codepen snippet I shared above, we saw how the browser rendered the boxes. Because of thier DOM order, the green box was farther below the stack than it peers.

But now it is on top of the rest. From the result in the Codepen playground, we can clearly see that the green box is being rendered above the pink box. How?

The green box being rendered on top of the rest of the other elements

Just like the rule of thumb clearly stated, setting the position property on any element in the DOM tells the browser to kindly re-do its calculations. Then, after those calculations, the browser decided to render the DOM element with the position property on top of any other elements regardless of their DOM order.

It is also worth mentioning that no matter the number of the z-index value we add for the other elements, they will never come on top of a positioned element. Yeah! I know you just had that euphoric revelation moment of "So this was the cause of my bug the other day at work".

You can play around with the playground by adding a z-index property to the other elements and adding a large value and see the result – take it up to 500 even. I assure you none of those elements will get placed on top of the positioned element.

Note: This doesn't apply to position: static. This is because position: static is the default positioned value assigned by CSS to all DOM elements. You can check it out by editing the playground above to have position: static.

You are probably thinking, "oh well, what if more than one element has the position property set. If you face this scenario, who wins the stacking context war?".

First I would like you to try it out. Try editing the playground above and setting the position properties on the two other elements.

When this happens, we have just evened all the elements by setting a position property. When the browser sees this, it returns to its default way of stacking these elements by following their DOM order. So it again renders the latter over the former just like how we stack up books. Check out the code snippet below to get a proper understanding.

<div class="green-box">  div>
<div class="pink-box">  div>
<div class="blue-box">  div>

div{
  width: 100px;
  height: 100px;
  border: 3px solid;

}

.green-box{
  background-color: green;
  position: relative;
}
.pink-box{
  background-color: hotpink;
  margin-top: -30px;
  margin-left: 20px;
  position: relative;
}
.blue-box{
  background-color: blue;
  margin-top: -30px;
  margin-left: 40px;
  position: relative;

}

This is how stacking context works in the browser. Adopting this mental model is one of the fundamental ways of truly understanding how z-index works.

From the explanations above and the code snippets we saw, you might be wondering: if the z-index won't work when we try to use it when sibling elements have the position property set, how then do we even use it?

Well, what we just experienced is how the browser decides stacking context by default. z-index is simply a property that allows us to override this default value.

But that comes with some rules of its own. We'll explore this in the section below.

How to Use the Z-index Property

If we are looking to change how things work and opt-out from the default way of how the browser renders and stacks DOM elements, CSS has provided us with a property called z-index. And we can use it to achieve this.

First let's demisfity the almighty z-index property:

The z in z-index refers to the z-axis. z-axis represents the 3 dimensional part of an element.

x-axis is left and right
y-axis is up and down
z-axis is forward and backward

The mental model is that z-index works like 3D – elements with a higher z-index are elevated and pushed closer to a user's view in the browser so that it looks like they are over/in front of the rest of the other elements.

This is the same way 3D billboards work, by pushing images closer to us optically so that if feels almost as if the characters in these billboards are jumping out of the screen. The z-index shares the same concept with a 3D billboard.

Just like every other CSS property with default values, the default value for the z-index property is auto, which can be interpreted as zero.

When we are using z-index on any DOM element, adding a value of 1 or above is a direct command/signal that tells the browser to push that particular DOM element so that it sits right in front of its siblings.

For us to be able to use z-index effectively, there are some rules guiding how it works. Understanding and properly digesting how these rules apply is very important as it takes you one step closer to being free from the z-index struggle and uneccassary bugs. Check out the code snippet below:

<div class="green-box">  div>
<div class="pink-box">  div>
<div class="blue-box">  div>

div{
  width: 100px;
  height: 100px;
  border: 3px solid;

}

.green-box{
  background-color: green;
  z-index: 6;
}

.pink-box{
  background-color: hotpink;
  margin-top: -30px;
  margin-left: 20px;
}
.blue-box{
  background-color: blue;
  margin-top: -30px;
  margin-left: 40px;
}

Even after adding a big z-index value to the green box it still doesn't comes on top the pink box

Isn't it surprising that, after setting a z-index value of 6 (a relatively big number for z-index), stacking context doesn't change?

The expectation after doing this is to see the green box being rendered on top of the rest the the boxes (since of course we know that z-index is used to get one element to be on top of the rest).

But in this case it is not working. Moments like this will lead to endless frustration and pulling out of hair and the rhetorical question: "Why aren't you not working?" and eventually a bad day at work.

I introduce you to the first rule of z-index:

`z-index` only works with positioned elements.

Now, I want you to go edit the playground and set position: relative on the green box and see the result. Try it by editing the Codepen playground above.

If you did, you will immediately see that the green box is now being rendered on top and the browser has re-calculated the stacking context and rendered the DOM elements accordingly via the new information it received. Always remember this first rule. See the first rule in action below:

<div class="green-box">  div>
<div class="pink-box">  div>
<div class="blue-box">  div>

div{
  width: 100px;
  height: 100px;
  border: 3px solid;

}

.green-box{
  background-color: green;
  z-index: 6;
  position: relative;
}
.pink-box{
  background-color: hotpink;
  margin-top: -30px;
  margin-left: 20px;
}
.blue-box{
  background-color: blue;
  margin-top: -30px;
  margin-left: 40px;
}

After setting a position property on the green box, the z-index now works properly, rendering the green box on top.

Next stop is the second rule – but before we go into the details and understand what that rule does, I want to introduce you to a little bug. And I want you to see if you know what is happening and if you can resolve it.

If you can't, don't worry, as I will be explaining it in great detail below.

<body>
  <header> This is a header header>
  <main> <p>Hello there I am the main p>
    <button> Click me button>

  main>

body>

@import url('https://fonts.googleapis.com/css2?family=Mulish:wght@200..900&display=swap');
body{
  font-family: 'Mulish', sans-serif;

}
header {
  background-color: hotpink;
  text-align: center;
  padding: 30px;
  position: relative;
  z-index: 2;
}

main {
  text-align: center;
  background-color: blue;
  color: white;
  padding: 30px;
  position: relative;
  z-index: 1;

}
button {
  margin: 0 auto;
  width: 90px;
  border: none;
  text-align: center;
  padding: 8px;
  background: white;
  box-shadow: 1px 2px 8px hsl(0deg 0% 0% / 0.25);
  border-radius: 6px;

  position: absolute;
  z-index: 999999;
  top: -12px;
}

From the code snippet above, we have seen yet another z-index issue that can lead to hours of debugging without even knowing what is wrong.

Going through the code, we can see that the button has a outrageous number as its z-index value, and yet it is not sitting on top of the header. This might make you take a step back and reflect on the first rule of z-index and say "But it is a positioned element, why is it not working?".

That brings us to the second rule of z-index:

A `z-index` property in an Isolated stacking context is not regarded outside the Isolated stacking context.

What does this mean? Let me break it down:

From the code above, we can see that the main has a position property and also a z-index property. The same thing applies to the header element – the browser has used this value and calculated the stacking context. Since the header has a higher z-index value, it rendered it on top. As simple as that.

Now, the button is a child of main that also has the position property set. It also a z-index set to even a higher number.

In reference to the second rule, since main has the z-index property which creates something called an isolated stacking context, the button element is not regarded when the browser tries to work up the new stacking context.

You can go ahead and remove the z-index property on the main element and see what happens.

If you did that, you likely saw that immediately the button was rendered on top of the header element.

This might be pretty confusing at first, but trust me – when you use it and pratice more with it, it'll stick. I have an analogy to help you create a mental model when you think of this second rule:

Captain analogy

In a plane, there are usually 2 pilots, both of whom are equally qualified to fly and captain an airplane. But only one of those 2 pilots are actually chosen to be the captain of that specific flight. As long as the chosen pilot is not missing, sick, or injured during the course of the flight, there is no need for the second pilot to assume being a captain.

But in a situation where something bad happens to the chosen pilot, the second pilot is allowed and mandated to be captain.

Use this same analogy on the main and button, main has already been assigned a captain by having the z-index property. Because of this, the z-index property of the button becomes useless not matter how big we bump up the numbers.

But once we take away the z-index property from the main , the button is now free to be the captain.

Incase you have forgotten what a stacking context means:

The stacking context is simply a term used to define how the browser decides which elements in the DOM comes first and which to "render" on top.

We have discussed extensively how stacking context works and how it's created, but below is a summary:

Setting a position property (relative, fixed or absolute) on a DOM element.
Setting the z-index property on a DOM element.
Setting opacity to a value less than 1.
Using the isolation property.
Using the transform, filter, clip-path, or perspective CSS properties.

This simply means that using any of the properties above tells the browser to calculate and see which DOM element should be rendered on top of the rest of the elements.

You can read more about how stacking context works on the MDN.

How to Debug the Z-Index

Before we wrap up this article, I want to introduce you to a new property that you can use alongside the z-index property. It helps you deal with stacking contexts in a more pleasant way.

I will do so by introducing a bug so we can see how to fix it. Check the codepen playground below to see:

<body>
  <header> This is a header header>
  <main>
        <button> Click here to suscribe button>
    <p>Hello there I am the main p>
    <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.   Reiciendis numquam sapiente veniam fugiat. Harum voluptatum est ab similique incidunt,Quae, amet rem. Minima vitae, accusantium corrupti dolorem perferendis qui magnam...[view the full code snippet on the codepen playground abovep>

  main>

body>

@import url('https://fonts.googleapis.com/css2?family=Mulish:wght@200..900&display=swap');
body{
  font-family: 'Mulish', sans-serif;

}
header {
  background-color: hotpink;
  text-align: center;
  padding: 30px;
  position: sticky;
  top: 0;
  z-index: 2;
}

main {
  text-align: center;
  background-color: blue;
  color: white;
  padding: 30px;
  position: relative;
  min-height: 100vh;
}
button {
  border: none;
  text-align: center;
  padding: 8px;
  background: white;
  box-shadow: 1px 2px 8px hsl(0deg 0% 0% / 0.25);
  border-radius: 6px;

  position: sticky;
  top: 0;
  right: 20px;
  margin-left: 100rem;
  z-index: 2;  
}

If you run the playground above and see the result you will notice an issue there. Here is what I'm trying to do:

We have a blog, and in every blog post we want a floating sticky button that says "Click here to subscribe" because of course we want more viewers subscribed to the blog.

We do this by adding the position: sticky on the button so that it is always floating and in view as the users read the blog post. Once they see it enough, maybe they'll decide to subscribe.

We also want this button to be adherent to the blog post itself, which means as soon as the blog post is no longer in view, there is no reason why the button should be there. Because of this, we made the button a child of the main element which contains the blog post.

While this is true, we also want the button to be above/in front of the content of the blog post, simply floating on top the posts' text. To do this we added a z-index property. Now, because we already have a position property, we were very confident that the button would be stacked on top of the content by the browser.

From the page, we also added a sticky header, so that the header is glued to the page and never scrolls away. We also want the header to be on top on the other elements, so the blog post and any other preceding DOM elements just slip under the header.

To accomplish this, we add a z-index value of 2 so it is pushed further up the stack and closer to the screen which renders it on top of the other DOM elements.

After doing this and feeling satisfied with our work, we notice that we have a bug (I hate bugs): the button is simply not doing what we want it do.

The button is actually going above the header instead of going below alongside the blog post as we intended.

This is a recipe for further frustration that causes quite a bit of pulling and screaming at the computer screen along with "Why is CSS so difficult?".

Try going over the code and figuring out what the issue really is. Then come back to this article and we will solve it together.

Remember our second rule of z-index? Where we used the Captain analogy to describe how stacking contexts are compared? That is what is playing out here.

Looking at the code, we can see that we created 2 stacking contexts:

When we used the positioned and z-index on the header element.
When we used the positioned and z-index on the button element.

From the points above we can see that these two elements are the ones being compared by the browser in order to create the correct stacking context.

Also remember we discussed that:

If two DOM elements have the exact same properties for creating a stacking context, the browser decides which comes out on top by following the DOM order. This means that the latter element comes on top of the former, just like in a stack of books.

That is how the browser decided that button has has to come on top. When we compare alongside the browser, we see that:

The header has position: sticky, but the button also has position: sticky. It doesn't matter which value is used as long as the element is using a position property.
The header has a z-index of 2 (because it wants to come on top), and the button also has a z-index of 2 (because it wants to be above the content of the blog).

This has left the browser with no other choice than to decide the winner by following the DOM order, which means that since button is the latter in the DOM order it will come on top of the header. Phew! What a bug.

How do we solve this? We can go back to our Captain analogy:

On a plane, there are 2 pilots, both of them are equally qualified to fly and captain the plane. But only one of those 2 pilots are actually chosen to be the captain for that flight. As long as the chosen pilot is not missing, sick, or injured, there is no need for the second pilot to assume being a captain.

But in a situation where something bad happens to the chosen pilot, the second pilot is allowed and mandated to be captain.

Remember that button is a child of main but the main has no z-index. This means it is not a captain, which also means there is no isolated stacking context hindering the button's z-index property from being disregarded. Instead, the browser will consider it and compare it with the header element to decide which element should be rendered on top.

We can resolve this by applying the second rule of z-index by simply creating an isolated stacking context. We do this by adding a z-index property and also setting a position property on the main element. Let's see this in the code snippet below:

<body>
  <header> This is a header header>
  <main>
        <button> Click here to suscribe button>
    <p>Hello there I am the main p>
    <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.   Reiciendis numquam sapiente veniam fugiat. Harum voluptatum est ab similique incidunt,Quae, amet rem. Minima vitae, accusantium corrupti dolorem perferendis qui magnam...[view the full code snippet on the codepen playground abovep>

  main>

body>

@import url('https://fonts.googleapis.com/css2?family=Mulish:wght@200..900&display=swap');
body{
  font-family: 'Mulish', sans-serif;

}
header {
  background-color: hotpink;
  text-align: center;
  padding: 30px;
  position: sticky;
  top: 0;
  z-index: 2;
}

main {
  text-align: center;
  background-color: blue;
  color: white;
  padding: 30px;
  position: relative;
  min-height: 100vh;
  position: relative;
  z-index: 1;
}
button {
  border: none;
  text-align: center;
  padding: 8px;
  background: white;
  box-shadow: 1px 2px 8px hsl(0deg 0% 0% / 0.25);
  border-radius: 6px;

  position: sticky;
  top: 0;
  right: 20px;
  margin-left: 100rem;
  z-index: 2;  
}

Tada! Solved.

Now we have handed the captain mantle to main who is a parent to the button. This forces the button to step aside. And since the z-index on the header is 2 (which is a bigger number than 1 which we set on the main), the button is now going under the header alongside the blog post.

This is because, just like the second rule of z-index explained, the z-index value on the button no longer has any effect on the stacking context decision made by the browser.

Here are the 2 rules of the z-index property again:

z-index only works with positioned elements.
A z-index property in an isolated stacking context is not regarded outside the isolated stacking context.

How to use the isolation property

While the above code clearly solved our problem, we are still left with something every developer hates – that is, having littered z-index all over our codebase, we can go on vacation for a month, come back to our codebase, and encounter yet another z-index bug. We might forget what some particular z-index value was even supposed to do. Then we'll remove it which will plunge ourselves into another endless round of bug fighting.

Instead of using position: relative; z-index: 1; on our main element to create the isolated stacking context, we can simply do this instead:

Using the isolation property to solve the bug

main {
  isolation: isolate;
}

The isolation property does only one thing which is: it creates a stacking context.

This is the simplest way to create a stacking context. It can be useful when you want to prevent the z-index values of child elements from affecting the layout of a webpage (except, of course, when we want it to do so). This property allows us achieve this without the burden of having the z-index every where in our code.

Conclusion

We have reached the end of this article. Hopefully you now understand the underlying mechanism behind how the browser stacks elements in the DOM (called a stacking context). You should also know how the z-index propery works, z-index rules, how to effectively use these rules.

I hope you learned a lot from this article, and I am looking forward to seeing you win every z-index battle you might face in future. You can always come back to this post and read it again.

For more CSS tips, follow me on Twitter.

Thanks for reading! See you next time.

How the Document Object Model Works in JavaScript – DOM Tutorial for Beginners

Boateng Dickson — Thu, 19 Jan 2023 15:21:29 +0000

The Document Object Model (DOM) is an essential part of web development. It provides a way for programmers to interact with and manipulate the structure of a website.

With the help of the DOM, developers can access and change the different parts of a webpage. This allows them to create dynamic and interactive websites, where user interactions can trigger changes in the page's layout and content.

Understanding the DOM is crucial for creating responsive and user-friendly websites. So in this article, we will delve deeper into what the DOM can do and how you can use it in JavaScript.

What is the DOM?

The DOM, or Document Object Model, is like a map of a website. Just like how a map shows you where all the streets and buildings are in a city, the DOM shows you where everything is on a website.

The DOM helps your computer understand the different parts of a website and how they are put together.

Just like you can use a map to find your way around a city, programmers can use the DOM to find different parts of a website and change their properties. For example, they can make a button change color when a user hovers over it or make pictures move around on the screen.

The DOM is like a big puzzle. But using JavaScript, we can move the puzzle pieces around and make a website look and work however we want it to work.

The DOM + JavaScript

JavaScript is a programming language that helps us interact with the DOM. The DOM and JavaScript are like two friends that work together to make websites cool and interactive. Again, the DOM is like a big map that shows where all the different parts of the website are located.

On the other hand, JavaScript is like a magic wand that can change a website by using the map (DOM) to find the different parts of the website. It can make a button change color when you click on it or make a picture move to a different spot on the page.

Together, the DOM and JavaScript make the website come alive and respond to what you do, like moving your mouse or clicking on a button.

In summary, the DOM is like a map that shows where everything is and JavaScript is like a magic wand that can change things on that map.

DOM Structure – Understanding the DOM Tree

Imagine a website is like a big book, and each page in that book represents a different part of the website. The DOM tree is like a table of contents for that book. It shows you all the different parts of the website, and how they are organized.

Each part of the website is called an "element" and these elements are arranged in a tree-like structure.

The top of the tree is called the "root" and it represents the entire website. From there, the tree branches out into different sections, like the headings, paragraphs, images, and others that make up the entire website.

Illustration of the DOM tree

Just like how the table of contents in a book helps you find specific pages, the DOM tree helps computers find specific elements on a website. In addition, it allows developers to access and change those elements, so they can make the website interactive.

In short, the DOM tree represents the structure of a website in a way that computers can understand. Developers can use it to access and manipulate different elements in that structure to create dynamic web pages.

How to Access the DOM

Accessing elements in the DOM means finding specific parts of a website and changing or manipulating them.

To access an element on a website, you need to know the specific element you want to access.

JavaScript provides different methods to access the elements in the DOM, such as getElementById, getElementsByTagName, querySelector, and querySelectorAll.

These methods allow you to find an element based on its id, tagname, or classname and select it for manipulation.

For example, you can access a button on a webpage and change its text or color when a user clicks on it. Or, you can access an image on a webpage and change it to a different image when a user hovers over it.

Here's an example of how you might use the DOM to access an element on a webpage:

Let's say you have a webpage that displays a list of students and you want to change the background color of a specific student when they are clicked.

You can use the DOM method getElementById to access the specific element that represents the student and then use the style property in JavaScript to change the background color of that element.

Here's how that might look:

<div id="student-list">
  <div id="student-1" class="student">Johndiv>
  <div id="student-2" class="student">Alicediv>
  <div id="student-3" class="student">Bobdiv>
div>

.student {
  padding: 40px;
  margin-bottom: 10px;
  cursor: pointer;
}
.student:hover {
  background-color: #f1f1f1;
}

let student1 = document.getElementById("student-1");

student1.addEventListener("click", () => {
  student1.style.backgroundColor = "lightblue";
});

In this example, JavaScript is using the getElementById method to select the element with the id "student-1" and it changes its backgroundColor property to "light blue" when you click on it.

Similarly, you can use getElementsByClassName to select all elements with a specific class and querySelector to select an element based on a CSS selector.

This is just a basic example, but it illustrates how you can use the DOM to access specific elements on a webpage and change their properties in response to user interaction.

How to Add, Remove, and Modify DOM Elements

Adding, removing, and modifying elements in the DOM refers to adding new elements to a webpage, removing existing elements, and changing the properties of existing elements.

For example, if you want to add a new button to a webpage, you would use JavaScript to create a new element and then use the DOM to add that element to the webpage. Similarly, if you want to remove an element, you would use the DOM to find the element and then delete it.

Modifying elements also involves making changes to the properties of an existing element. For example, you could use the DOM to change the text inside a button.

Here’s how you can express this in code.:

    <div id="wrapper" class="btn-wrapper">
      <button id="create-btn" class="btn">Create new buttonbutton>
    div>

.btn-wrapper {
  display: flex;
  height: 100vh;
  justify-content: center;
  align-items: center;
  gap: 10px;
  flex-wrap: wrap;
}

let createButton = document.getElementById("create-btn");
let wrapper = document.getElementById("wrapper");

createButton.addEventListener("click", () => {
  let newButton = document.createElement("button");
  newButton.innerHTML = "Click me";
  wrapper.appendChild(newButton);
});

In the above example, we are creating a new button element and setting the text inside the button to "Click me". Then we're using the appendChild method to add this new button element to the webpage.

Recap

The Document Object Model (DOM) is an essential tool for creating interactive, dynamic web pages using JavaScript. It allows developers to access and manipulate the contents of a webpage in real time.

Understanding the DOM tree and how to access, add, remove, and modify elements is crucial for JavaScript developers.

We've seen how the DOM represents a webpage as a tree of objects and how we can use different methods like getElementById, getElementsByTagName, querySelector, and querySelectorAll to access specific elements on a webpage. With these methods, we can change the content, style, or layout of a webpage after it has loaded in the browser.

Additionally, we've seen how to add new elements to a webpage, remove existing elements, and change the properties of existing elements.

Conclusion

I hope this article has given you a better understanding of the Document Object Model and how to use it to create dynamic web pages.

Remember that the DOM is a powerful tool that you can use to create amazing websites, so don't be afraid to experiment and try new things.

Thanks for reading! Kindly share this article and follow me on Twitter @alege_dev for updates on future posts.

What is XSS? How to Protect Your Website from DOM Cross-Site Scripting Attacks

freeCodeCamp — Tue, 03 Jan 2023 19:51:56 +0000

By Andrej Kovacevic

Website security issues and vulnerabilities are a global problem as cyber security vulnerabilities are increasing. We have seen a major rise in the average number of these cases in the past few years, and 2021 saw an all-time high.

So in this tutorial, we are going to talk about DOM XSS cross-site scripting security issues and what impact they can have on your data. Make sure you read till the end. Let's begin by brushing up on some basics about DOM XSS cross-site script security.

What is Cross-Site Scripting?

Cross-site scripting, also called XSS, is a website security issue that compromises user information and data when those people use a vulnerable application. The attacker can use this to circumvent the origin policy, which separates two websites from one another.

Attackers may use XSS to pretend to be a user, perform actions that a user would, and gain access to the user’s information. This can also allow the attackers to gain full access to the user’s information if they have permissions and privileges. It can also take over the complete actions and performance of the website if this continues.

To help you better understand these types of attacks, we are going to discuss some fundamentals of how XSS operates and what it does.

How Does XSS Work?

Cross-site scripting uses technology to manipulate a vulnerable site so that it sends dangerous JavaScript to users. This allows the attacker to gain complete access to the site when the script gains access to the user’s system. But the user needs to execute the JavaScript for this first.

Types of XSS Attacks

Reflected XSS:

This malicious script comes from the HTTP request. This is the most basic type of XSS attack, where an application could receive malicious data and reflect it immediately towards the user.

The attacker’s payload must be part of the request sent to a server, which is then reflected and executed onto the user’s application.

One example of this would be an attacker convincing someone to click on a phishing link before it takes effect.

Stored XSS:

This malicious script comes from the database of the website. The attacker inputs the malicious request onto the server where it could stay permanently unless manually addressed.

For example, the attacker could input a malicious script into a comment field, which would be on display for everyone who visits the page. Even without directly engaging with the script, page visitors could fall victim to this attack.

DOM-based XSS:

This more advanced vulnerability exists in client code and not on the server code. DOM-based XSS is neither reflected nor stored onto the server, but exists in a page’s Document Object Model (DOM). The web application reads the malicious code and executes it in the browser as part of the DOM, which is more difficult to detect as it doesn’t come through the server.

The security vulnerabilities involved in DOM XSS attacks are a serious concern for most websites. We are going to talk about some of the most common risks that you have on open source web building platforms such as WordPress with regard to DOM - XSS hacks.

This allows the attacker to execute malicious JavaScript code in the victim's browser, potentially allowing the attacker to steal sensitive information or perform other harmful actions on the victim's behalf.

Here is an example of a DOM-based XSS attack:




<p>Enter a URL to display: <input type="text" id="user-input" />p>
<button onclick="displayURL(document.getElementById('user-input').value)">
 Display URL
button>


<div id="display">div>

Remember that this tutorial is purely for educational purposes, to help you recognize and defend against XSS. You shouldn't use this information to perform any of these sorts of attacks.

DOM XSS – WordPress Vulnerabilities

The main target of DOM XSS attacks on WordPress is its users. Users enter their details, accounts, and site credentials to access their WordPress sites and this is what the DOM XSS attacks aim to compromise online. The attackers can use DOM XSS to get access to user information and details with a single click.

This also includes your cookies, information, and others, making it one of the most common WordPress security vulnerabilities.

Following are some of the top WordPress website security issues you should bear in mind to ensure better cross-site script security.

Accessing a User's Private Information

One of the most common WordPress security vulnerabilities involved with DOM XSS attacks is that attackers can gain useful information and even completely take over a user’s site. This can often make things escalate fast and cause complete data compromise.

Impersonating a User

Attackers can pretend to be the user, to interact with the victim’s online users, clients, and customers to gain their information.

Compromising a Site

Another common cross-site scripting security issue with websites is that these attacks can compromise the website and take access from the user. This includes displaying deviating content on the site (or content that is not originally from the site).

Other cases may involve changing the way WordPress looks online. Other people may also exploit the website by installing explicit content.

In more severe cases, attackers may impact the WordPress site through phishing attempts. This is a common concern for web builder security vulnerabilities that we will discuss shortly.

The impact of XSS cross script-security issues varies for each website. However, WordPress sites are usually at a higher risk of these kinds of compromises because users save their personal information on the website. The risk increases further if the user is an admin, as the attacker can compromise the complete WordPress site.

DOM XSS and Closed Code Web Builder Platforms

Website builders such as Weebly, Squarespace, Webflow and Wix, unlike WordPress, are non-open source platforms. They allow users to intuitively create websites for their businesses via drag and drop DIY features without any coding or design experience. They also work hard to protect their users' security.

There are tons of useful tools, options, easy-to-integrate dashboards, and hosting opportunities available for users instilling their trust in these platforms. Website security issues are of course a major concern for the majority of the users on these platforms.

Many website builders try their best to protect the sites of their users from hacker threats. But out of all of the website builders available, I believe that Wix follows the NIST framework for cyber security the best and has become a major contributor to improvements in this field.

Wix protects users on their sites from being vulnerable to these kinds of attacks online with tools such as:

Third-party updates that project against DOM XSS attacks
A secure Sockets Layer that protects against unwanted access for users on site
Round-the-clock secure web hosting which protects users against any kind of unwanted logins or phishing attempts.
Granting its users admin privileges, which restrict site access and control to the original owner only
Highlighting weak passwords and suggesting more difficult-to-decipher passwords.

Ways to Protect Against XSS Attacks

Defending your system and users against XSS attacks often requires a multifaceted approach to ensure that your servers and applications are protected against various types of attacks.

The best way to defend against XSS attacks is to properly sanitize user input. This means making sure that any user input is properly encoded so that it cannot be interpreted as code by the browser.

Additionally, you can use a web application firewall (WAF) to help identify and block XSS attacks. It's also a good idea to keep your software and web applications up to date, as many XSS vulnerabilities can be mitigated by simply applying the latest security patches.

Input Validation

This programming technique ensures that only properly-formatted data can enter a software system. Websites can either allow or block certain values to ensure that no XSS can penetrate their servers.

Escaping or Encoding User Input

Encoding and escaping changes user input to make them safer for the system. Encoding replaces special characters with more harmless equivalents (for example, translating < to <), while escaping adds special characters to protect against injection attacks.

Implementing a Content Security Policy (CSP)

Content security policies help administrators mitigate XSS attacks by restricting the resources a page can load at a given time. These resources can include scripts and images that could potentially harm clients and servers.

Bottom Line

DOM XSS cross-site scripting security issues are a serious concern for users on websites. But closed code web building platforms provide features like admin privileges, password best practices, 3^rd party updates, and much more. These features make them a more secure website building option than many open code platforms.

You can also prevent XSS attacks by filtering input once it arrives. You can do this by ensuring that only valid input is accepted.

When encoding data on output, the process should be done in HTTP responses so it will not be read as active content. More complex coding might be required, such as applying combinations of URL, JavaScript, CSS, and HTML encoding, depending on the context of output.

Keep response headers in check so browsers will have an appropriate interpretation of content.

Finally, use Content Security Policy (CSP) to minimize the severity of XSS attacks.

"Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';">

This CSP will allow your website to load scripts and styles from the same origin (that is, your own website), but it will block scripts and styles from external sources. It will also allow the use of inline scripts and styles, but it will block eval() statements, which can be used to execute arbitrary code.

Of course, this is just a simple example, and you can customize your CSP to suit your specific needs. For more information on how to use CSPs to defend against XSS attacks, you can refer to the Content Security Policy Level 2 specification.

Feature image via Unsplash (Florian Olivo).

Event Bubbling in JavaScript – How Event Propagation Works with Examples

freeCodeCamp — Mon, 31 Oct 2022 21:04:17 +0000

By Dillion Megida

HTML elements receive different types of events, from click, to blur, to scroll, and so on.

One behavior these events have in common is Event Bubbling. I'll explain what this behavior means in this article.

I also made a video version of this article which you can watch here.

What is Event Bubbling?

Event Bubbling is a concept in the DOM (Document Object Model). It happens when an element receives an event, and that event bubbles up (or you can say is transmitted or propagated) to its parent and ancestor elements in the DOM tree until it gets to the root element.

This is the default behavior of events on elements unless you stop the propagation which I'llexplain at the end of this article

Let's look at an example so I can better explain how event bubbling works.

The HTML:

<body>
  <div>
    <span>
      <button>Click Me!button>
    span>
  div>
body>

The CSS:

body {
  padding: 20px;
  background-color: pink;
}

div {
  padding: 20px;
  background-color: green;
  width: max-content;
}

span {
  display: block;
  padding: 20px;
  background-color: blue;
}

The result:

The button is a child of the span, which in turn is a child of the div, and the div is a child of the body. The DOM tree would look like this:

DOM tree for this interaction

When you click the button, you can think of it like you're also clicking the span (the blue background). This is because the button is a child of the span.

It's also the same thing with the div and the body. When you click the button, it's just like you're also clicking the span, div, and body because they are the button's ancestors. This is the idea of event bubbling.

An event doesn't stop at the direct element that receives it. The event bubbles up to its ancestors, until it gets to the root element.

So if the button receives a click event, for example, the span, div, and body (up until html, the root element) respectively receive that event:

Illustration showing how event bubbling works

Also, if you click on the blue box (span), the button doesn't receive the click event as it is not a parent or ancestor or the span. But, the div, body, and HTML would receive the event.

The same thing happens if you click on the div – the event is propagated to the body and html element.

How to Handle Events that Bubble

The "Event Bubbling" behavior makes it possible for you to handle an event in a parent element instead of the actual element that received the event.

The pattern of handling an event on an ancestor element is called Event Delegation. You can read more about it here.

Let's create some event listeners and handlers:

const body = document.getElementsByTagName("body")[0]
const div = document.getElementsByTagName("div")[0]
const span = document.getElementsByTagName("span")[0]
const button = document.getElementsByTagName("button")[0]

body.addEventListener('click', () => {
  console.log("body was clicked")
})

div.addEventListener('click', () => {
  console.log("div was clicked")
})

span.addEventListener('click', () => {
  console.log("span was clicked")
})

button.addEventListener('click', () => {
  console.log("button was clicked")
})

Here, we've selected the body, div, span, and button elements from the DOM. Then we added the click event listeners to each of them and a handler function that logs "body was clicked", "div was clicked", "span was clicked", and "button was clicked", respectively.

What happens on the console when you click on the pink background (which is the body) is:

body was clicked

When you click on the green background (which is the div), the console shows:

div was clicked
body was clicked

The "click" event on the body element is triggered even though the div element was the target element clicked because the "click" event bubbled from the div to the body.

When you click on the blue background (which is the span), the console shows:

span was clicked
div was clicked
body was clicked

And, lastly, when you click on the button, the console shows:

button was clicked
span was clicked
div was clicked
body was clicked

How to Stop Event Bubbling

Event Bubbling is a default behavior for events. But in some cases, you might want to prevent this.

Let's say, for example, from our HTML code, that you want the div to open a modal when it is clicked. For the button, on the other hand, you want it to make an API request when it is clicked.

In this case, you may not want the modal to open when you click the button. You might want the modal to only open when you actually click it (and not when you click any of its children). This is where preventing event propagation comes in.

To prevent event bubbling, you use the stopPropagation method of the event object.

When handling events, an event object is passed to the handling function:

button.addEventListener("click", (event) => {
  // do anything with the event object
}

The event object contains properties that have information about the event that was triggered and the element it was triggered on. This object also contains methods – one of which is stopPropagation().

The stopPropagation method of an event prevents the event from propagating to the parents and ancestors of the element the event was triggered on.

We can use this in the JavaScript code from above:

body.addEventListener('click', () => {
  console.log("body was clicked")
})

div.addEventListener('click', () => {
  console.log("div was clicked")
})

span.addEventListener('click', () => {
  console.log("span was clicked")
})

button.addEventListener('click', (event) => {
  event.stopPropagation()
  console.log("button was clicked")
})

With this, when you click on the button, all you get in the console is:

button was clicked

The button's parents and ancestors do not receive the click event as it doesn't bubble up from the button.

You can also stop the bubbling from a different element like this:

body.addEventListener('click', () => {
  console.log("body was clicked")
})

div.addEventListener('click', () => {
  console.log("div was clicked")
})

span.addEventListener('click', (event) => {
  event.stopPropagation()
  console.log("span was clicked")
})

button.addEventListener('click', () => {
  console.log("button was clicked")
})

With the stopPropagation() called on the span's event listener, and the button clicked, on the console you get:

button was clicked
span was clicked

The event bubbles from the button to the span but stops there because the propagation is stopped at this point.

Wrapping Up

When elements receive events, such events propagate to their parents and ancestors upward in the DOM tree. This is the concept of Event Bubbling, and it allows parent elements to handle events that occur on their children's elements.

Event objects also have the stopPropagation method which you can use to stop the bubbling of an event. This is useful in cases where you want an element to receive a click event only when it is clicked and not when any of its children elements are clicked.

stopPropagation and preventDefault are methods of the event object for stopping default behaviors. Here is an article on the difference between these methods.

DOM - freeCodeCamp.org

What is the Virtual DOM in React?

What Is the Virtual DOM and How Does It Work?

Comparing the Virtual DOM to the Real DOM

Benefits of Using the Virtual DOM in Web Development

Simplified Development

Improved Performance

Enhanced User Experience

Cross-platform Development

Common Misconceptions About the Virtual DOM

The Virtual DOM Is a Browser Feature

The Virtual DOM Replaces the Real DOM

React is the Only Library and Framework that Uses the Virtual DOM

The Virtual DOM Solves All Performance Problems

The Virtual DOM and Shadow DOM Are the Same

Real DOM vs Virtual DOM vs Shadow DOM

Conclusion

Learn React and Next JS

JavaScript in the Browser – How the Document Object Model (DOM) and Events Work

Prerequisites:

Table of Contents

What is the Browser Object Model (BOM)?

Window Object

What is the Document Object Model (DOM)?

DOM Tree Structure

Types of Nodes in the DOM Tree

, , , and so on. These nodes make up the backbone of the DOM tree and form the structure of the HTML document.

Node Relationships

, and elements, and they are descendants of the element.

How to Work with DOM Elements

Traversing the DOM:

How to Make Your Websites More Interactive

Wrapping Up

How the Z-index Property Works – Stacking Order of Elements in CSS

The Problem with the Z-index Property in CSS

What is Stacking Context in CSS?

Positioned Elements in CSS

How to Use the Z-index Property

z-index only works with positioned elements.

A z-index property in an Isolated stacking context is not regarded outside the Isolated stacking context.

Captain analogy

How to Debug the Z-Index

How to use the isolation property

Conclusion

How the Document Object Model Works in JavaScript – DOM Tutorial for Beginners

What is the DOM?

The DOM + JavaScript

DOM Structure – Understanding the DOM Tree

How to Access the DOM

How to Add, Remove, and Modify DOM Elements

Recap

Conclusion

What is XSS? How to Protect Your Website from DOM Cross-Site Scripting Attacks

What is Cross-Site Scripting?

How Does XSS Work?

Types of XSS Attacks

Reflected XSS:

Stored XSS:

DOM-based XSS:

DOM XSS – WordPress Vulnerabilities

Accessing a User's Private Information

Impersonating a User

Compromising a Site

Social Engineering

DOM XSS and Closed Code Web Builder Platforms

Ways to Protect Against XSS Attacks

Input Validation

Escaping or Encoding User Input

Implementing a Content Security Policy (CSP)

Bottom Line

Event Bubbling in JavaScript – How Event Propagation Works with Examples

What is Event Bubbling?

How to Handle Events that Bubble

How to Stop Event Bubbling

Wrapping Up

,
, , and so on. These nodes make up the backbone of the DOM tree and form the structure of the HTML document.

, and
elements, and they are descendants of the element.

`z-index` only works with positioned elements.

A `z-index` property in an Isolated stacking context is not regarded outside the Isolated stacking context.