Type selector
p, h1 or button has low specificity. Useful for base styles.
Platform under construction
Specificity
Specificity measures how strongly a selector targets an element. It is powerful, but if you overuse it, your stylesheet starts fighting itself.
.card__title { color: #8cffc1; }
.card.card--featured .card__title { color: #62d5ff; }
#special-card .card__title { color: #ffb55f; }
Cascade & Control
Specificity is selector weight, not selector quality.
Specificity is one part of the cascade. When two declarations compete and the cascade reaches selector strength, the browser compares selector specificity.
IDs are stronger than classes. Classes, attributes and pseudo-classes are stronger than type selectors. Inline styles are stronger than normal stylesheet selectors.
The goal is not to write the most specific selector. The goal is to write selectors that are strong enough, readable and easy to override on purpose.
Class selector
.card is the normal styling workhorse. Reusable and manageable.
ID selector
#hero is strong and usually too rigid for reusable styling.
Inline style
style="" beats normal selectors and should be rare in site CSS.
Visual model
Control CSS by understanding the browser decision path.
The browser does not apply styles emotionally. It follows a priority system. These diagrams make that priority visible before you start changing declarations.
button
One type selector. Light and easy to override.
.button
One class selector. Ideal for components.
.nav .button
Two classes. Stronger, but still reasonable.
#checkout
One ID. Very strong for normal styling.
Examples
Write CSS that wins for a reason.
Specific enough, still easy to override
.card {
padding: 2rem;
}
.card--featured {
border-color: #8cffc1;
}
.card__title {
font-size: 2rem;
}
Specificity arms race
#page main .cards article.card.featured h2.title {
color: red;
}
body #page .cards .card h2.title.title {
color: blue;
}
Rules that matter
Control comes from reducing surprise.
CSS becomes easier when every override has a reason. If a rule wins by accident, the next developer has to debug your intention instead of the code.
Use class selectors for components
Classes are reusable and do not lock you into exact page structure.
Avoid IDs for styling systems
IDs are hard to override and usually belong more to anchors or JavaScript hooks.
Keep chains short
Long descendant chains break when markup changes.
Do not duplicate classes for weight
.button.button.button is a warning sign.
Use modifiers instead of deeper selectors
.button--danger is clearer than .modal footer div .button.
Inspect specificity before overriding
A crossed-out declaration may have lost to a stronger selector.
Production thinking
The cascade is architecture, not trivia.
Why does this matter?
Specificity decides how hard future changes become. Low, intentional specificity makes CSS feel calm; accidental high specificity makes every small change expensive.
Accessibility
High-specificity rules can accidentally override focus states, font sizes and contrast fixes. Keep accessibility selectors easy to win.
Production note
A scalable stylesheet should avoid specificity spikes. If one selector is much heavier than the rest, document the reason or simplify it.
SEO note
Specificity itself is not an SEO factor, but maintainable CSS helps preserve readable, stable pages over time.
Live code lab
Change the CSS and watch the interface respond.
The preview runs in an isolated iframe. Links and forms stay inside the practice area, so you can experiment without leaving the lesson.
Mini assignment
Try this now.
- Remove the ID selector and run the preview.
- Change .card.card--featured .card__title to .card--featured .card__title.
- Add a simple .card__title rule at the bottom and predict whether it wins.
Practice assignment
Do this before moving to the next lesson.
- Write four selectors with different specificity levels.
- Rank them before testing.
- Refactor the strongest selector into a cleaner class-based selector.
Try it yourself
Compare selector weight in a component
Self-check
Before you continue, prove that you understand Specificity.
Answer these questions before moving on. If the answer is vague, inspect the lab example and trace which declaration wins.
- Can you explain specificity without saying "the last one always wins"?
- Can you identify why an ID selector is hard to override?
- Can you choose class selectors for a reusable component?
- Can you spot a specificity arms race?
- Can you lower specificity without changing the design?
Senior audit upgrade
Selector weight and selector quality are different.
A selector can be powerful and still be a bad choice. Good CSS uses enough specificity to be clear, but not so much that every future rule becomes a fight.
:where() is zero
Use :where() for low-pressure defaults because it contributes no specificity.
:is(), :not(), :has()
These use the highest specificity inside their selector list, so one ID inside can make the whole selector heavy.
Avoid arms races
If you need longer and longer selectors, the architecture probably needs cleaning.