WordPress CSS Specificity: A WordPress 6.9 Case Study

Got a call from a client last week. An agency we work with. They’d just rolled out the WordPress 6.9 update to one of their sites, and suddenly, things looked broken. The headings inside some custom-built “feature boxes” on the homepage had this bizarre, chunky padding that wasn’t there before. Total mess.

It had all the signs of a classic WordPress CSS specificity problem. One of those little things that can drive you crazy for hours if you don’t know what you’re looking for.

The “Quick Fix” Trap

My first instinct, and the one a lot of devs would have, was to just write a CSS override. Slap a more specific selector on it, maybe even an !important if I was feeling lazy, and call it a day. Problem solved.

And yeah, that would have worked. For about five minutes.

But that’s how you end up with a stylesheet full of patches and hacks. A year from now, someone else (or future me) would be trying to figure out why this one heading won’t style correctly, only to find my !important rule buried in the code. It’s bad practice. It’s technical debt.

So, I dug deeper. The issue wasn’t a plugin or the theme. It was a subtle, but important, change in WordPress core itself.

How WordPress 6.9 Fixes Heading Block CSS

For years, the CSS that applied padding to Heading blocks with a background color was a bit too greedy. The selector looked something like this:

h1.has-background,
h2.has-background,
h3.has-background {
  padding: ...;
}

See the problem? That style applies to any <h1>, <h2>, etc., that has the .has-background class. It doesn’t care if it’s a real .wp-block-heading block or just a heading element inside another block, like my client’s feature box. The Accordion block is another common victim of this.

As the official dev note on the source url https://make.wordpress.org/core/2025/11/12/heading-block-css-specificity-fix-in-wordpress-6-9/ explains, WordPress 6.9 fixed this. The new selector is much smarter:

h1:where(.wp-block-heading).has-background,
h2:where(.wp-block-heading).has-background,
h3:where(.wp-block-heading).has-background {
  padding: ...;
}

Here’s the kicker. The :where() pseudo-class is the clever part. It lets them add the .wp-block-heading class for specificity, ensuring the style only targets actual Heading blocks, but it keeps the selector’s overall specificity score at a low 0-1-1. This means it’s still easy for theme developers to override without starting a CSS specificity war.

So, What’s the Point?

This change is a good thing. It makes WordPress’s core styles more predictable and less likely to leak where they don’t belong. But it also means that if your theme or a plugin was relying on that old, buggy behavior, things might look different after the update.

• Don’t just patch it. Resist the urge to write a quick !important fix.
• Investigate the selector. Use your browser’s inspector to see where the unwanted style is coming from. If it’s the core h...has-background style hitting a non-heading block, you’ve found your culprit.
• The Right Fix: Your theme needs to explicitly add the padding styles to its own custom components now, rather than piggybacking on a core style that was never meant for it.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

This little episode is a perfect example of why understanding the “why” is more important than just knowing the “how.” The “how” was a five-second CSS patch. The “why” led to a proper, stable fix and a deeper understanding of how the block editor is evolving. And that’s the kind of knowledge that separates the pros from the amateurs. Trust me on this.