Most developers learn CSS specificity once.

They remember:

#id > .class > div

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;
}

HTML:

<div class="some-library">
  <div class="modal"></div>
</div>

Many developers expect:

.modal

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

Specificity Table

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

Contains:

button     → 0-0-1
.primary   → 0-1-0

Total:

0-1-1

Another selector:

#header button.primary

Contains:

#header   → 1-0-0
button    → 0-0-1
.primary  → 0-1-0

Total:

1-1-1

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;
}

HTML:

<div id="header">
  Hello
</div>

Result:

Red

Why?

Because:

#header = 1-0-0
div     = 0-0-1

Specificity wins before source order.

❌ Myth #2 — Higher z-index Always Wins

This causes countless production bugs.

Developers often write:

.modal {
  z-index: 99999;
}

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;
}

Even with:

999999

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;
}

Microfrontend B

.layout .modal {
  z-index: 100;
}

Specificity:

.modal
0-1-0

.layout .modal
0-2-0

Microfrontend B wins.

Even if your CSS is still loaded.

Why My Fix Worked

Originally:

.modal {
  z-index: 9999;
}

But another selector had higher specificity.

So I wrapped the modal:

<div class="dialog-wrapper">
  <Modal />
</div>

Then:

.dialog-wrapper .modal {
  z-index: 9999;
}

Before:

.modal
0-1-0

After:

.dialog-wrapper .modal
0-2-0

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)

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)

Specificity:

1-0-0

Because:

#header

is most specific.

2️⃣ :not()

Many developers think:

:not(.hidden)

adds nothing.

Not true.

:not() itself doesn't contribute specificity.

But selectors inside it do.

Example:

:not(.hidden)

Specificity:

0-1-0

3️⃣ :where()

One of the most underrated CSS features.

Example:

:where(.btn)

Specificity:

0-0-0

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.

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

into:

Predictable Engineering

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.