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
| 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
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.