DEV Community: Marwan Ahmed

Ending z-index confusion, once and for all.

Marwan Ahmed — Tue, 02 Sep 2025 19:32:31 +0000

Yes, we've all been there... writing z-index: 99999; and almost smashing the screen because one element isn't being put on top of another.

Before you start reading, if your goal is to skim through the article in order to find a quick fix for your bug, I'm sorry to disappoint you (I'm not actually), you won't find what you're looking for.

The goal of this article is to make you super confident the next time you're adding random numbers in a z-index... that your solution won't work!

First, let's mention two basic but very important rules when it comes to stacking element on top of each other:

If an element does not have a defined z-index, it will have a value of z-index: auto
In order for z-index to work, we must define a position value other than static
z-index will work with flex and grid without defining a position
Elements further down the document sit on top of elements that appear before them.

In order to understand the problems with z-index, it's crucial that we grasp a very important concept called Stacking Contexts.

Stacking Contexts

Stacking contexts is the reason why your 99999 doesn't work. So, what in the world is that thing that is causing developers pain?

Let's make this simple using a dumb analogy. Let's assume that we're comparing the ages of parents and children. We have 2 fathers and each father has 2 sons. Ahmed has Omar (yes, it's my brother's name) and Marwan. Mark has John and Jack.

The rules are that we cannot compare the age of a child to the age of a father, and we cannot compare the age of a child to the age of a child of another father. Meaning we can only compare either the ages of the two fathers (Ahmed and Mark), or the ages of two brothers.

When a father has his first child, he starts creating a family (stacking context). It's logically impossible for one of his children to be older than him. His children cannot outgrow him no matter how tall they are or how much weight they put on (z-index: 99999;).

<div class="position-relative z-index-2" id="Ahmed">
   <p class="position-relative z-index-10" id="Marwan"></p>
   <p class="position-relative z-index-1000" id="Omar"></p>
</div>

<div class="position-relative z-index-1" id="Mark">
   <p class="position-relative z-index-10" id="John"></p>
   <p class="position-relative z-index-1000" id="Jack"></p>
</div>

In this example, the div with id Ahmed creates a stacking context when it has position: relative and z-index: 2, so it starts having its own family.

So, the child with id Omar, will never grow above its parent, although he has a much higher z-index.

In the same family, we can compare both brothers, so Omar is above Marwan.

Now, what if we want to compare Ahmed with Mark? Since they both created their own families (stacking contexts), they're both fathers, so we can compare them. In this case, Ahmed will be above Mark, since Ahmed has a higher z-index.

How about comparing Mark with Omar? As mentioned above, we cannot compare fathers to children of other fathers. In this case, we will have to compare Mark to the Omar's father Ahmed.

This is the gist of stacking contexts and why sometimes higher z-index doesn't make any difference.

There are scenarios where children can be above their parents. This is when the parent doesn't have a position other than static.

In this case, the parent did not create a new stacking context, so the child is being compared in the root stacking context, even if the parent has a z-index.

Referring to our analogy, it's as if the child Omar has grown to be a father and is now being compared to other fathers.

Solutions

Knowing the problem is half the solution. Since the problem is now clear, you might think "Well, if the problem is that the child is trapped inside it's parent's stacking context, maybe the solution is to find a way to move the child outside". You'd be exactly right, and that's what Vue and React teams have done when they created Portal and Teleport.

Portal and Teleport are used to teleport a certain element (dropdown, modals, popovers) to the body, in order to free it from it's parent's stacking context.

Other solutions might include restructuring your html, playing with elements' position property, you get the idea.

Summary

Here's a flowchart that summarizes the above, and helps you grasp the concept clearly. (I asked ChatGPT to do it but it failed miserably so I did it. The disappointments of AI...)

Hopefully that's the end of random 9's thrown around in your code.

Maybe you can even show-off to your team and explain to them what you've understood 😉.

If you have any questions or any feedback, drop them below 👇. I'd love to hear from you.

NPM Packages: To install or not to install

Marwan Ahmed — Tue, 02 Jan 2024 08:27:35 +0000

Are you a developer who installs A LOT of packages in your projects?
Are you a developer who occasionally installs some packages?
Are you a developer who never installs packages and builds everything from scratch?
Well, either way, this is for you! This article is an attempt to strike the fine balance of when and when not to install an npm package.

First off, whether you own a business and your app contains a lot of third-party libraries, or you’re a developer whose job involves a lot of npm installing, your future doesn’t look particularly bright.

In order to discover how to decide on installing a package, let’s first breakdown why making it a habit to install packages is bad for you.

Suppose you’re a business-owner whose business is booming. Your e-commerce website is doing great and gaining a lot of traffic. One day, you open the website and you find it completely broken.

After some investigation, you find out that the app’s code, which is built-up from numerous packages, is not working anymore.

You later find out that the person who built one of your packages that the app’s dependent on has decided to shut it down. Basically your entire business was resting on the whims of some developer.

If you’re thinking that this is a bit far-fetched, this has actually happened before, check this.

Now let’s look at some more probable disadvantages of npm packages:

1.Cost

While it may seem so, installing packages is not actually for free.

The thing you pay the most is performance. The performance of your app is directly affected by the size of the package. By performance I mean, the loading time and the responsiveness of app (how fast the app responds to user interaction)

This is by no means a cheap cost. The app performance can be the difference between a business's success and failure.

2.Security Risk

If you have a habit of installing a lot of packages, chances are your app will be prone to security issues. Because you’re basically adding a lot of code to your app that you don’t really know a lot about. Some of the code might have security vulnerabilities which can be exploited by hackers.
So if you’re a business-owner that’s a very dangerous thing to have.

3.Learning Curve

As a passionate-learner, this is for me by far the biggest disadvantage. Regularly installing packages can turn you into a lazy, incompetent developer. After all, it’s not very hard to type npm install.

When I first knew about npm packages, it was like magic for me. I thought people who built packages were like developers who only worked for mega companies. I could picture them wearing these hoodies, putting on their nerdy glasses while working with the lights off.
Later, I found a package that’s whole purpose is to check whether a number was even or odd, and that was pretty much it.

The moment I realized that developers who build packages are actually normal people, and that I have the capability to build any package I want, shifted my mindset hugely. I’m actually now building my own package which is something that, at some time, I thought I would be able to do when I’m close to retirement.

Instead of installing a package, why not make it?
Instead of just using a package from its documentation, why not read its code? Actually, I would argue now it’s a must to perform thorough code review for the package you’re using.

You will learn a lot, whether by taking in different ideas and being encouraged to make your own package, or by being trained to look for things that you can improve on in a piece of code. And of course, you will have full knowledge of the ins and outs of your application.

So, if you’re used to installing packages in order just to get things done, as time will pass you will find yourself way behind the pack.

You might be thinking now, ‘wow packages are really bad, and if they’re so bad why are people making them?!’. Well, that’s not actually the case.

Packages are a way of developers helping each other. You can learn a lot from other people’s code as well as saving time while building your app.

But the number one benefit from npm packages is Time. Packages save developers hours and hours of time building everything from scratch.

But I’ve just mentioned above that it’s better to build your own code for learning’s sake so how does that work?!

Actually, while working in a company, most of the time you won’t have the luxury of time to build everything from scratch, as companies always want fast development in order to generate fast revenue. So, you will find yourself thinking a lot; should I install a package for this feature or should I do it from scratch?

Let’s talk about the factors that can help us decide on the matter:

The most important factor is time. Time is basically how urgent the business request is vs how much time it would take to build it. If you find yourself in a very tight time-frame and the feature is somehow complex, then the reasonable decision would be to install a package (but choose wisely!).

Another situation where it would be more reasonable to install a package is if the feature you’re building requires a huge learning curve. I mean let’s not kid ourselves here you’re probably not gonna build your charts from scratch!

But let’s not stop here. If you find yourself having to install a package, after you finish the feature, make a plan to build it from scratch yourself, whether to replace the one you installed, or even if you build it on your own time for learning’s sake.

Summary

The next time you’re not sure whether or not to install a package, think of the factors we mentioned; Cost, Security Risk, Learning Curve and Time, and make a decision.
If you decided on installing the package, remember to:

Choose the package wisely
Review the package’s code
Make a plan to build it from scratch