— how CSS decides which voice speaks louder

If the cascade is CSS’s referee,
specificity is its volume knob.

Every selector has a certain “weight”,
and when two rules want to style the same element,
the heavier one wins.

As always in the Ai era,
We don’t need to memorize the formula.
We just need to understand the shape of the idea:

Some selectors whisper.
Some speak normally.
Some shout.
Some scream.

Once we feel that, we can guide AI to write rules that behave the way we intend.

Specificity is simply:

How strongly a selector claims the right to style something.

The browser compares the strength of each selector
and chooses the strongest one.

Here’s the intuitive hierarchy:

• element selectors (p, h1) — whisper
• class selectors (.intro, .button) — speak normally
• ID selectors (#header) — shout
• inline styles (style=“color:red”) — scream
• !important — breaks the system entirely

We don’t need to memorize numbers.
We just need to feel the relative weight.

When a rule “does nothing,”
it’s almost always because a louder selector is already speaking.

AI often generates CSS like:

.button {
  color: blue;
}

…but the page still shows red buttons.

Why?

Because somewhere else, there’s a louder rule:

#header .button {
  color: red;
}

The ID selector wins.
It shouts louder.

Once we understand this, we can guide AI:

• “Lower the specificity.”
• “Avoid IDs here.”
• “Use a class instead.”
• “Make this selector stronger without using !important.”

We’re not memorizing rules —
we’re shaping the conversation.

We can think of specificity
as three buckets:

1. IDs
2. Classes, -attributes, pseudo‑classes
3. Elements, pseudo‑elements

When comparing two selectors,
CSS checks the buckets in that order.

That’s the whole idea.

We don’t need the math.
We just need the shape.

IDs are extremely loud.
They make rules hard to override.
They force us into specificity battles.
They push us toward !important.

In modern CSS, we rarely need IDs.

Classes give us:

• flexibility
• composability
• predictable specificity
• easier overrides
• calmer code

When AI generates ID‑based selectors,
we can gently redirect it:

“Use classes instead of IDs.
Keep specificity low so we can override things easily.”

This keeps our CSS breathable.

The cascade decides which rule wins,
but specificity decides how loudly
each rule speaks.

The two forces work together:

• If two rules have different specificity,
  the more specific one wins — even if it appears earlier.
• If two rules have the same specificity,
  the later one wins.

— the moment we realize something deserves its own home

Specificity becomes a concept the moment we notice that it’s no longer just a detail
— it’s a pattern shaping our entire stylesheet.

We feel this moment when:

• a rule “does nothing,” even though it should
• a class can’t override an ID
• a component behaves differently in two places
• AI generates selectors that are louder than we intended
• we’re tempted to reach for !important

These are signals — gentle reminders that specificity isn’t just a mechanic.
It’s a force in the system,
and forces deserve our attention.

This is the moment to pause and ask:

“Which selector is louder?”  
“Do we need to lower the volume?”

Once we ask those questions,
the CSS becomes readable again.
Predictable again.
Ours again.

Here’s the moment when we bring AI into the conversation:

“Why is this rule losing the cascade?”

“Which selector is more specific?”

“Rewrite this selector with lower specificity.”

“Make this rule win without using !important.”

“Convert these ID selectors into class selectors.”

We’re not asking AI to memorize the algorithm.
We’re asking it to help us shape the forces.

Specificity is the weight of a selector —
the louder the selector, the more likely it is to win.

Once we feel this,
CSS stops being mysterious
and becomes a quiet, predictable system
we can collaborate with.

• Suggested Next Reading: Inheritance — How Styles Pass Down the Tree

_{Tony de Araujo —New York | Lisbon}

• Top↑
• Back to Topic ↔
• Home←