A client called me last week, a large e-commerce shop, practically screaming because their carefully built H2 styles were being mangled inside the Block Editor. On the front end everything looked crisp. In the editor it fell apart. It is the usual specificity war, with core block styles bullying the theme’s CSS, and it is enough to make any senior dev eye the nearest window.
Years ago my instinct would have been to slap an !important on every heading class and move on. I have done it. You know how that ends: six months of whack-a-mole with CSS overrides until the stylesheet is 5,000 lines of regret. So I got clever instead and wrote highly specific selectors aimed at nested containers in the editor. That held until a minor WordPress update shifted the DOM structure underneath it. The fix had to come from core.
What the WordPress 6.9 CSS specificity fix actually does
The latest Dev Chat Agenda confirms WordPress 6.9 is dealing with it. The release sits at Release Candidate 3 and includes a Heading Block CSS specificity fix aimed squarely at these conflicts. It belongs to a wider push to make the editor show what the site shows, without developers writing “hacky” CSS to get there.
Until now, core styles often carried more specificity than theme-provided ones in certain contexts, theme.json especially. In 6.9 the way those styles get injected has been refined, so a rule like bbioon_custom_heading_styles behaves the way you wrote it. Here is roughly how we are structuring theme overrides now that specificity is more predictable:
// Simplified theme.json approach for 6.9
{
"version": 3,
"settings": {
"blocks": {
"core/heading": {
"typography": {
"fontWeight": "700",
"lineHeight": "1.2"
}
}
}
},
"styles": {
"blocks": {
"core/heading": {
"css": "padding-bottom: 0.5rem; border-bottom: 2px solid var(--wp--preset--color--primary);"
}
}
}
}The CSS work is not the only thing in 6.9. The Interactivity API and DataViews land as well. DataViews is worth a look if you do much custom admin work, though how enjoyable that look is depends on how much of it you do. Core is moving more of the admin toward a data-driven model, which helps performance and means learning a few new patterns. I am already looking at the new Abilities API for tightening client-side permissions on some of our messier WooCommerce builds.
Preparing for the December 2nd launch
WordPress 6.9 is slated for December 2, 2025. If you have not pulled RC3 down to test your current projects against it, you are cutting it fine. One topic from the Dev Chat was the distinction between browser support for the admin and browser support for the front end. It is a subtle split, and it matters if you support clients on legacy corporate infrastructure. Keeping the front-end output compatible while the admin leans on modern APIs is a balancing act we do most weeks.
It gets complicated fast. Between the specificity changes and the new iframe integration for the post editor, there is plenty of surface area for something to break. If you would rather not spend the next major update debugging someone else’s mess, drop my team a line. We have probably seen it before and have a fix ready.
So stop fighting the editor with CSS hacks and use what core is handing you. It saves a lot of gray hair over the life of a project.
