Cascade, specificity, and debugging

When two rules conflict, the browser does not guess—it follows the cascade. Understanding it saves hours of “why is my color wrong?”

Resolution order (simplified)

1. Origin and importance (!important).
2. Specificity — inline style > ID > class/attribute/pseudo-class > type.
3. Source order — later rules win ties.

Specificity intuition

• p — low.
• .btn — higher.
• #save — higher still (avoid styling with IDs).
• style="color:red" on the element — very high.

Debugging workflow

1. Open DevTools → inspect the element.
2. Find the winning declaration (often struck-through rules above it).
3. Trace back to the file or block; fix specificity or remove duplicates.

Team habit

Prefer one clear class per component state (.btn.is-primary) instead of long chained selectors like main div ul li a.

Important interview questions and answers

1. Q: What beats equal-specificity rules?
   A: Source order—whichever rule appears last in the cascade.
2. Q: Why avoid `!important` in app CSS?
   A: It breaks predictable overrides and leads to escalation wars.
3. Q: How do you lower specificity deliberately?
   A: Replace IDs with classes, shorten selectors, split components.