Explain :is() vs :where() specificity and when to pick :where()

What's really being asked

This tests whether you understand specificity as an architectural constraint rather than a trivia fact. Senior engineers building design systems must control the specificity of base styles so that product teams can override them with simple class selectors without resorting to !important or artificially inflated selectors.

The full answer

First, the exact rule: :where() always has zero specificity, while :is() takes on the specificity of the most specific selector in its argument list. Second, the practical implication: grouping selectors with :is() can accidentally create a high-specificity barrier that is hard to override, whereas :where() gives you the grouping convenience without the specificity penalty. Third, a concrete scenario where you would intentionally choose :where(): global reset styles, utility classes, or design system primitives that must remain easy to override. Fourth, mention that both use forgiving selector parsing, so invalid selectors in the list are ignored rather than invalidating the whole rule, though this is a secondary point and not the primary difference.

The mistakes people make

Saying the two are interchangeable or differ only in browser support. Claiming that :where() has lower specificity but not stating it is exactly zero. Giving an example where you choose :where() solely because it is newer or shorter, without mentioning specificity architecture. Failing to mention that :is() specificity is determined by its most specific argument, not an average or sum. Describing the difference in vague terms like one is stronger without quantifying the zero versus most-specific rule.

What usually comes next

How would you use :where() in a CSS reset or normalize stylesheet? If a team complains that utility classes are being beaten by base styles, how would :where() fix that? Can you combine :where() with :is() in the same selector, and what would the resulting specificity be? How does forgiving selector parsing help when using vendor-prefixed or cutting-edge pseudo-classes? When would you actually want the higher specificity of :is()?

A concrete example

Imagine a design system provides a reset for heading margins: :where(h1, h2, h3, h4, h5, h6) { margin-top: 0; }. Because :where() has zero specificity, a product developer can override it later with a single class like .article-title { margin-top: 2rem; } using 0-1-0 specificity. If the system had used :is(h1, h2, h3, h4, h5, h6) instead, the reset would carry 0-0-1 specificity, tying with element selectors and beating some utility classes, forcing developers to fight the cascade.