DEV Community

Cover image for 🚨 CSS Specificity — The Hidden Reason Your UI Breaks
Fazal Mansuri
Fazal Mansuri

Posted on

🚨 CSS Specificity — The Hidden Reason Your UI Breaks

#css #frontend #learning #webdev

Most developers learn CSS specificity once.

They remember:

#id > .class > div
Enter fullscreen mode Exit fullscreen mode

Then move on.

Until one day…

Everything looks correct.

The CSS is present.

The selector is correct.

The z-index looks higher.

And yet the UI is broken.

That’s when CSS specificity stops being a beginner topic and becomes a production debugging problem.

The Production Incident That Started This

Recently, I was working on a microfrontend application.

Everything worked fine initially.

I opened a page, launched a modal and the UI looked correct.

Then I navigated to another microfrontend.

Its CSS got loaded.

After returning to the original microfrontend, suddenly:

❌ Modal appeared behind page content
❌ Overlay behaved incorrectly
❌ z-index looked correct but wasn't working

DevTools showed my CSS rule still existed.

Yet another CSS rule was winning.

The culprit?

CSS Specificity.

🧠 What is CSS Specificity?

CSS specificity is the algorithm browsers use to decide:

Which CSS rule wins when multiple rules target the same element.

Browsers don't simply apply:

"The last CSS rule."

That's one of the biggest misconceptions.

Specificity is calculated first.

Only when specificity is equal does source order become important.

⚔️ Example 

.modal {
  z-index: 9999;
}

.some-library .modal {
  z-index: 100;
}
Enter fullscreen mode Exit fullscreen mode

HTML:

<div class="some-library">
  <div class="modal"></div>
</div>
Enter fullscreen mode Exit fullscreen mode

Many developers expect:

.modal
Enter fullscreen mode Exit fullscreen mode

to win because the value is larger.

But CSS doesn't compare values first.

It compares selectors.

🧮 How Specificity Works

Specificity is usually represented as:

ID - CLASS - TYPE
Enter fullscreen mode Exit fullscreen mode

Specificity Table

Selector Specificity
* 0-0-0
div 0-0-1
.modal 0-1-0
[type="text"] 0-1-0
:hover 0-1-0
#dialog 1-0-0
Inline Style Highest

MDN defines specificity as the weight browsers calculate to determine which declaration gets applied when multiple selectors match the same element.

Example Calculation

Selector:

button.primary
Enter fullscreen mode Exit fullscreen mode

Contains:

button     → 0-0-1
.primary   → 0-1-0
Enter fullscreen mode Exit fullscreen mode

Total:

0-1-1
Enter fullscreen mode Exit fullscreen mode

Another selector:

#header button.primary
Enter fullscreen mode Exit fullscreen mode

Contains:

#header   → 1-0-0
button    → 0-0-1
.primary  → 0-1-0
Enter fullscreen mode Exit fullscreen mode

Total:

1-1-1
Enter fullscreen mode Exit fullscreen mode

This selector wins.

❌ Myth #1 — Last CSS Always Wins

Many developers believe:

The CSS rule written last wins.

Not always.

Example:

#header {
  color: red;
}

div {
  color: blue;
}
Enter fullscreen mode Exit fullscreen mode

HTML:

<div id="header">
  Hello
</div>
Enter fullscreen mode Exit fullscreen mode

Result:

Red
Enter fullscreen mode Exit fullscreen mode

Why?

Because:

#header = 1-0-0
div     = 0-0-1
Enter fullscreen mode Exit fullscreen mode

Specificity wins before source order.

❌ Myth #2 — Higher z-index Always Wins

This causes countless production bugs.

Developers often write:

.modal {
  z-index: 99999;
}
Enter fullscreen mode Exit fullscreen mode

And expect it to appear above everything.

Not necessarily.

Because:

z-index works inside stacking contexts.

🧠 What is a Stacking Context?

A stacking context is a separate layering environment.

Example:

.parent {
  position: relative;
  z-index: 1;
}

.child {
  position: absolute;
  z-index: 999999;
}
Enter fullscreen mode Exit fullscreen mode

Even with:

999999
Enter fullscreen mode Exit fullscreen mode

the child cannot escape its parent's stacking context.

This is why modal, tooltip, dropdown, and popover bugs often feel confusing.

The Microfrontend Problem

This is where specificity becomes extremely important.

Imagine:

Microfrontend A 

.modal {
  z-index: 9999;
}
Enter fullscreen mode Exit fullscreen mode

Microfrontend B 

.layout .modal {
  z-index: 100;
}
Enter fullscreen mode Exit fullscreen mode

Specificity:

.modal
0-1-0

.layout .modal
0-2-0
Enter fullscreen mode Exit fullscreen mode

Microfrontend B wins.

Even if your CSS is still loaded.

Why My Fix Worked

Originally:

.modal {
  z-index: 9999;
}
Enter fullscreen mode Exit fullscreen mode

But another selector had higher specificity.

So I wrapped the modal:

<div class="dialog-wrapper">
  <Modal />
</div>
Enter fullscreen mode Exit fullscreen mode

Then:

.dialog-wrapper .modal {
  z-index: 9999;
}
Enter fullscreen mode Exit fullscreen mode

Before:

.modal
0-1-0
Enter fullscreen mode Exit fullscreen mode

After:

.dialog-wrapper .modal
0-2-0
Enter fullscreen mode Exit fullscreen mode

Now my selector became more specific and started winning.

The CSS value never changed.

Only specificity changed.

And the issue disappeared.

🚨 Why This Happens More in Microfrontends

Microfrontends often share:

  • Same DOM
  • Same global CSS
  • Same class names
  • Same browser environment

Problems include:

  • CSS leakage
  • Style collisions
  • Unexpected overrides
  • Load-order changes after navigation

This makes specificity bugs significantly more common.

Modern CSS Specificity Features Developers Often Miss

1️⃣ :is()

Example:

:is(.btn, .link)
Enter fullscreen mode Exit fullscreen mode

The :is() pseudo-class itself doesn't add specificity.

Instead, it takes the specificity of the most specific selector inside it.

Example:

:is(.btn, #header)
Enter fullscreen mode Exit fullscreen mode

Specificity:

1-0-0
Enter fullscreen mode Exit fullscreen mode

Because:

#header
Enter fullscreen mode Exit fullscreen mode

is most specific.

2️⃣ :not()

Many developers think:

:not(.hidden)
Enter fullscreen mode Exit fullscreen mode

adds nothing.

Not true.

:not() itself doesn't contribute specificity.

But selectors inside it do.

Example:

:not(.hidden)
Enter fullscreen mode Exit fullscreen mode

Specificity:

0-1-0
Enter fullscreen mode Exit fullscreen mode

3️⃣ :where()

One of the most underrated CSS features.

Example:

:where(.btn)
Enter fullscreen mode Exit fullscreen mode

Specificity:

0-0-0
Enter fullscreen mode Exit fullscreen mode

Always.

:where() intentionally has zero specificity.

This makes it extremely useful for:

  • Design systems
  • Component libraries
  • Shared UI frameworks

Because consumers can easily override styles.

How to Debug CSS Specificity Issues

When CSS isn't applying:

Check these in order:

1. Is the rule present?

Open DevTools.

Verify the CSS exists.

2. Is it crossed out?

Crossed-out CSS usually means:

Another rule won.

3. Which selector is winning?

DevTools shows the winning selector.

Inspect it carefully.

4. Compare specificity

Many bugs become obvious here.

5. Check CSS load order

When specificity is equal:

Last rule wins.
Enter fullscreen mode Exit fullscreen mode

6. Check stacking contexts

Especially for:

  • Modals
  • Dropdowns
  • Tooltips
  • Popovers

7. Check portals

React portals often render outside expected DOM hierarchy.

This changes how CSS behaves.

🎯 Best Practices

✅ Prefer class selectors over IDs

✅ Avoid deeply nested selectors

✅ Use low-specificity CSS in shared libraries

✅ Use :where() for easily overridable styles

✅ Be careful with global CSS in microfrontends

✅ Avoid excessive !important

Final Thoughts

Most developers think CSS specificity is a beginner topic.

In reality:

It's one of the most common reasons production UIs break unexpectedly.

Especially in:

  • Large applications
  • Design systems
  • Microfrontends
  • Shared component libraries

The tricky part is that the CSS often looks correct.

The rule exists.

The value is correct.

And yet another selector silently wins.

Understanding specificity deeply transforms CSS debugging from:

Trial and Error
Enter fullscreen mode Exit fullscreen mode

into:

Predictable Engineering
Enter fullscreen mode Exit fullscreen mode

Key Takeaways

  • CSS does not simply apply the last rule
  • Specificity determines which selector wins
  • Higher z-index does not always mean higher visibility
  • Microfrontends make specificity issues more common
  • :is(), :not(), and :where() have special specificity behavior
  • !important should be a last resort
  • DevTools can quickly reveal specificity conflicts when used correctly

Understanding CSS specificity is one of those skills that feels minor — until it saves you hours of debugging a production UI issue.

Top comments (0)