CSS :where() Selector: The Zero-Specificity Superpower

Ever had that moment when you’re wrestling with CSS specificity like it’s some kind of digital Sumo champion that keeps sitting on your beautiful styles? Yeah, me too. About sixteen times last Tuesday, actually.

But what if I told you there’s a CSS selector that’s been hiding in plain sight that could make your specificity woes vanish faster than my motivation after opening Twitter? Enter the :where() pseudo-class – the unsung hero of modern CSS that deserves its own cape and theme music.

Here’s where :where() becomes absolutely brilliant for visual effects — ever tried to override default box shadows in a component library or theme, only to find yourself writing increasingly ridiculous selectors like .my-component.override.please-work-this-time button:hover? The beauty of :where() is that it lets you define your shadow effects with zero specificity, meaning they can be easily overridden without turning your CSS into a specificity arms race.

This is particularly handy when you’re experimenting with different shadow combinations across your site. You can use :where() to set baseline shadow effects that won’t interfere with more specific styling later on. And honestly, if you’re still hand-coding all those shadow values, you’re making life harder than it needs to be — tools like 365i’s box shadow generator let you perfect your shadow effects visually, then you can drop them into a :where() selector knowing they won’t cause specificity headaches down the line. It’s like having your cake and eating it too, except the cake is beautifully maintainable CSS and somehow that makes it taste even better.

---

The Problem With Specificity (Or: Why I Started Drinking Coffee)

If you’ve built websites for longer than a week, you’ve probably experienced some variation of this conversation with yourself:

“Why isn’t my style applying?”
Adds another class
“Still nothing?!”
Throws in an ID
“FOR THE LOVE OF—”
Types !important while feeling deeply ashamed

That’s the CSS specificity war we’ve all fought. It’s a complex battle system where selectors compete based on their “weight” in the specificity hierarchy. IDs outrank classes, which outrank elements, and once you throw pseudo-classes and attributes into the mix… well, that’s when I usually make another coffee.

“In CSS, specificity is the algorithm used to determine which CSS rule is applied when multiple rules could style the same element. It’s basically the browser’s way of deciding ‘who’s the boss’ when conflicting styles exist.” – MDN Web Docs

For years, our options were limited: refactor everything, use even more specific selectors (hello, .sidebar .widget .widget-content p span.highlighted), or surrender to the dark side and use !important. None of these are particularly elegant solutions.

---

Enter :where() – The Specificity Ninja

Think of :where() as that friend who’s brilliant at diffusing tense situations. Released as part of CSS Selectors Level 4 specification and now supported in all modern browsers, this pseudo-class has one superpower that makes it absolutely brilliant:

It has zero specificity impact. Zilch. Nada.

Here’s how it works:

/* This has a specificity of 0,0,0 */
:where(.header, .footer) a {
  color: blue;
}

/* So even this simple selector can override it */
a {
  color: red;
}

Did you catch that? Even though we’ve written what looks like a reasonably specific selector (targeting links in header and footer), the specificity is completely neutralized by :where(). This means any other selector, even a simple element selector, can override it.

And that’s the magic.

---

Real-World Magic (Not the Disappointing Kind)

Let’s look at how this transforms real-world CSS scenarios. If you’re trying to improve your site structure as mentioned in our Ultimate Guide to Site Structure & Internal Linking, clean CSS organization should be part of your strategy.

Before :where() – The Specificity Nightmare

/* Base styles - specificity: 0,0,1 */
button {
  padding: 8px 16px;
  border-radius: 4px;
}

/* Primary button - specificity: 0,1,1 */
.button-primary {
  background: blue;
  color: white;
}

/* Secondary button - specificity: 0,1,1 */
.button-secondary {
  background: grey;
  color: black;
}

/* Danger button - specificity: 0,1,1 */
.button-danger {
  background: red;
  color: white;
}

/* When you later need to apply a global modifier like "small"... */
/* This needs higher specificity to override the button types */
.button-primary.small, 
.button-secondary.small, 
.button-danger.small {
  padding: 4px 8px;
  font-size: 12px;
}

This approach works, but it doesn’t scale well. What happens when you need another size, or a disabled state, or a loading state? You end up with increasingly complex and specific selectors.

After :where() – The Zen Garden

/* Button types with zero specificity */
:where(.button-primary, .button-secondary, .button-danger) {
  padding: 8px 16px;
  border-radius: 4px;
}

/* Button styles with minimal specificity */
.button-primary {
  background: blue;
  color: white;
}

.button-secondary {
  background: grey;
  color: black;
}

.button-danger {
  background: red;
  color: white;
}

/* Modifiers can have minimal specificity and still override */
.small {
  padding: 4px 8px;
  font-size: 12px;
}

See what happened there? We’ve flattened the specificity hierarchy, making it much easier to apply overrides without specificity conflicts. This approach aligns perfectly with modern CSS methodologies like utility-first CSS.

---

When to Use :where() (And When Not To)

As with everything in web development, it’s not always sunshine and rainbows. Here’s when :where() shines:

Perfect For:

• Base component styles: Define foundational styles without locking yourself into specificity battles later.
• Theme systems: Create theme variations that can be easily overridden.
• Utility classes: Ensure your utility classes work regardless of where they’re applied.
• Default states: Set default styles that should yield to more specific intentions.

If you’re redesigning your website and following our advice on 5 Big Choices for Web Design Customers in 2025, adopting :where() in your CSS strategy should definitely be consideration number 6.

Maybe Avoid For:

• Critical styles that must never be overridden: Since the whole point is to make overriding easier, don’t use it for styles that should be bulletproof.
• Styles where the cascade is important: Sometimes you want specificity to work its magic naturally.

“The best CSS is like a well-designed building – it has a solid foundation that supports many different configurations without requiring constant structural changes.” – CSS-Tricks

---

The Difference Between :where() and :is()

“Wait,” I hear you saying, “isn’t this just like :is()?”

Almost! The :is() pseudo-class also groups selectors, but critically, it takes on the specificity of its most specific argument. That’s a key difference that affects how you’d use each one.

/* This takes the specificity of .sidebar (0,1,0) */
:is(.header, .sidebar, footer) a {
  color: blue;
}

/* This has zero specificity (0,0,0) regardless of what's inside */
:where(.header, .sidebar, footer) a {
  color: blue;
}

In my experience working on projects like the ones highlighted in Top 5 Website Design Trends Every Business Owner Should Know About in WordPress, understanding these nuances can save hours of debugging and frustration.

:where() in the Wild: A Case Study

Last month, I was updating a client’s e-commerce site that had grown… organically, shall we say. The CSS was a tangled mess of specificity quicksand where simple changes required archaeological excavation.

The checkout button styles were particularly problematic:

/* Original CSS */
#checkout-section .product-list .item .button.buy-now {
  background: green;
  color: white;
  /* 50 more lines of specific styling */
}

/* Needed to add a disabled state, but this wouldn't override */
#checkout-section .product-list .item .button.buy-now.disabled {
  background: grey;
  opacity: 0.7;
  cursor: not-allowed;
}

Even with what should have been equal specificity, the disabled state wasn’t applying properly because of how other styles were cascading. The solution? Refactor using :where():

/* Refactored base styles */
:where(#checkout-section .product-list .item) .button.buy-now {
  background: green;
  color: white;
  /* Other styles */
}

/* Now the disabled class works perfectly */
.button.disabled {
  background: grey !important; /* Was able to remove this after refactoring */
  opacity: 0.7;
  cursor: not-allowed;
}

The result? A more maintainable codebase and a client who didn’t have to keep paying me to fix mysterious styling bugs. (Though, perhaps I should keep that advantage to myself…)

---

Browser Support: Can I Actually Use This?

The eternal question for any exciting CSS feature! The good news is :where() has excellent support across modern browsers. It’s supported in:

• Chrome 88+ (Jan 2021)
• Firefox 78+ (June 2020)
• Safari 14+ (Sept 2020)
• Edge 88+ (Jan 2021)

If you’re still supporting Internet Explorer… well, first, my condolences, and second, you’ll need a fallback strategy. But for most modern projects, you’re good to go.

If you’re considering updating your site to use more modern CSS features like this, you might find our article on WordPress Turbo Hosting to Supercharge Your Website helpful for optimizing performance with these new techniques.

---

How to Start Using :where() Today

Ready to add this magical selector to your toolkit? Here’s a simple upgrade path:

1. Identify specificity pain points: Look for places in your CSS where you’re fighting specificity battles (hint: search for !important).
2. Refactor base components: Start with reusable components that have variant classes.
3. Create a zero-specificity foundation: Move your base styles into :where() selectors, keeping your variants cleaner.
4. Test thoroughly: Because this changes the fundamental way styles cascade, test across pages and scenarios.

If you want to learn more about how to make your CSS more maintainable, our guide on Using Clamp() for Fluid Fonts in Elementor showcases another modern CSS technique that pairs beautifully with :where().

---

Conclusion: The Humble Hero Your CSS Deserves

In the ever-expanding universe of CSS tricks and techniques, :where() stands out not because it’s flashy, but because it solves a fundamental problem that has plagued CSS authors since the beginning: managing specificity.

By giving us a tool to group selectors without the specificity baggage, :where() enables more maintainable, scalable CSS architectures. It’s particularly valuable when you’re looking to maintain sites over the long term, as we discuss in The 7 Deadly Sins of WordPress Maintenance.

So the next time you find yourself reaching for that !important declaration, consider whether :where() might offer a more elegant solution. Your future self – and whoever inherits your code – will thank you.

---

 

				
					/* This has the specificity of #sidebar (1,0,0) - heavyweight */ 
:is(#sidebar, .widget) p { color: red; } 

/* This has specificity of (0,0,0) - featherweight */ 
:where(#sidebar, .widget) p { color: blue; }
				
			

				
					/* Perfectly valid - specificity determined by .important */
:is(:where(.header, .footer), .important) p {
  color: purple;
}
				
			

				
					@media (max-width: 768px) {
  :where(.card, .panel) {
    padding: 10px;
  }
}
				
			

				
					// SCSS with :where()
.container {
  :where(h1, h2, h3) {
    margin-bottom: 1rem;
    
    &:hover {
      color: blue;
    }
  }
}
				
			

				
					.container :where(h1, h2, h3) {
  margin-bottom: 1rem;
}
.container :where(h1, h2, h3):hover {
  color: blue;
}
				
			

				
					/* Base styles for all browsers */
.card, .panel {
  padding: 16px;
}

/* Enhanced control for modern browsers */
:where(.card, .panel) {
  padding: 16px;
}