How is CSS specificity calculated for a complex selector?
This tests ID-CLASS-TYPE algorithm fluency. A strong answer gives the three-column tally, counts IDs, classes or attributes, and types in order, and notes combinators add zero. A red flag is counting combinators or mixing inline styles into selector scores.
What's really being asked
The interviewer wants to know if you understand specificity as a three-column weight rather than a single integer, and whether you can apply it to a real selector without guessing. Senior engineers should be able to explain why specificity conflicts happen in design systems and how to avoid them.
The full answer
First, define the three categories in order of weight: ID, CLASS, and TYPE. Second, explain that the final score is not a base-ten number but a tuple like one-two-three, where the leftmost nonzero column wins. Third, walk through the provided selector piece by piece: ul is a type selector, hash nav is an ID selector, the greater-than combinator is ignored, li is a type selector, dot active is a class selector, the next greater-than combinator is ignored, a is a type selector, and the attribute selector href caret equals https is a class-level selector. That yields a specificity of one ID, two CLASS-level selectors, and three TYPE selectors, written as one-two-three. Fourth, explicitly state that combinators such as child, descendant, adjacent sibling, and general sibling add zero specificity, as do the universal selector and anything inside a where pseudo-class.
The mistakes people make
A common wrong answer is counting combinators as type selectors, which would incorrectly inflate the score. Another red flag is treating specificity as a single number, such as claiming one-zero-zero equals ten and zero-eleven-zero equals eleven, because ID always beats any number of classes. Some candidates also incorrectly rank attribute selectors below classes or claim pseudo-elements belong in the CLASS column. Mentioning inline styles or important as part of the selector score is also a mistake, since those are cascade origin and importance concerns, not selector specificity.
What usually comes next
The interviewer may ask how you would resolve a specificity war in a large codebase, which opens the door to discussions about cascade layers, container queries, or using where to zero out specificity. They might also ask what happens when two selectors have identical specificity, leading to order of appearance and scoping proximity. A third follow-up could be asking you to compare this selector against one with an inline style or an important declaration.
A concrete example
For the selector ul hash nav greater-than li dot active greater-than a href caret equals https, the breakdown is: one ID for hash nav, two CLASS-level items for dot active and the attribute selector href caret equals https, and three TYPE items for ul, li, and a. The specificity tuple is one-two-three. If it competed against a rule with just hash nav, the one-two-three rule would win on the CLASS column because both have one ID but the first has two classes versus zero.
Interview question
In a specificity conflict between `#header` and a selector with eleven classes, which statement is true?
- a.The `#header` selector wins because the ID column outweighs any number of classesCorrect
- b.The eleven-class selector wins because eleven simple selectors outweigh one
- c.The `#header` selector wins because inline styles are included in the selector score
- d.The eleven-class selector wins because its specificity sums to a larger integer than the ID
Why? this is the answer
The card explains that specificity is a tuple where the leftmost nonzero column wins, so one ID always beats any number of classes. Option D is tempting because it reflects the common error of collapsing the tuple into a single integer.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #css
- #specificity
- #frontend
- #design-systems
- #interview
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on css — each one lists the topics its interview covers.
See open roles