Your Custom CSS Is Being Ignored — And Block Patterns Are Why

Let's be honest about something that doesn't get talked about enough in WordPress developer circles: a lot of the custom CSS being written today is effectively dead weight. It sits in style sheets, looks perfectly reasonable, and does almost nothing — because the block editor has fundamentally changed where styles actually live and how they get applied.

This isn't a complaint about Gutenberg. It's a reality check about how WordPress development has evolved and why developers who haven't updated their mental model are fighting a battle that already ended.

The Old World vs. the Block World

For most of WordPress's history, CSS was king. You wrote styles in your theme's style.css, stacked specificity rules, maybe threw in a !important or two when things got weird, and that was the job. The DOM was predictable. Class names were stable. You knew where to look.

Block patterns changed that contract. When a pattern gets inserted into the editor, it brings its own inline styles, block gap settings, color assignments, and spacing values — all baked in through block attributes rather than class names. Those attributes render as inline styles, which means they sit at a higher specificity than virtually anything in your external style sheet.

So you write .wp-block-group { padding: 2rem; } and nothing happens. The block already has style="padding-top:var(--wp--preset--spacing--50)" sitting right on the element. Your rule never stood a chance.

theme.json Is the New Style Sheet — Sort Of

Here's where the philosophical shift really kicks in. WordPress introduced theme.json as a way to define design tokens — spacing scales, color palettes, typography settings — that feed directly into the block editor's controls. When a user sets padding through the sidebar, they're pulling from the values you defined in theme.json. That's actually elegant.

But a lot of developers are treating theme.json as a configuration file they set once and forget, then going right back to writing CSS for everything else. That's where the disconnect happens. In the block era, theme.json isn't supplementary — it's the primary styling interface for a huge chunk of what you used to handle in CSS.

Color? Define your palette in theme.json and let blocks reference it. Typography? Set your fluid type scales there. Spacing? Build your spacing scale and let the editor consume it. When you do this properly, you're not fighting inline styles — you're feeding the system that generates them.

Block Patterns Are a Packaging Problem

Block patterns are genuinely useful. Registering a reusable layout that editors can drop in with one click is a real productivity win. The problem is how they're often built.

A pattern that hardcodes specific hex values, arbitrary pixel padding, and custom font sizes as block attributes is a maintenance nightmare. Every instance of that pattern in the site now carries those values as inline styles, completely disconnected from your design system. Change your brand color? You're not changing it in one place — you're hunting through every pattern that ever got inserted.

The fix isn't to avoid patterns. It's to build patterns that reference your theme.json presets instead of hardcoding values. Use var(--wp--preset--color--primary) instead of #3a86ff. Reference your spacing scale instead of typing padding: 48px. When your pattern uses preset values, updating theme.json actually propagates — the way it's supposed to.

When Custom CSS Still Makes Sense

None of this means CSS is obsolete. There are plenty of places where custom CSS is still the right tool.

Complex hover states, focus styles, pseudo-element decorations, responsive behavior that goes beyond what the block controls offer — these still belong in your style sheet. Animation and transition logic isn't going into theme.json anytime soon. Layout edge cases that the block editor can't express through its sidebar controls still need CSS.

The key distinction is: are you writing CSS to style a structural or interactive behavior, or are you writing CSS to set a color, a spacing value, or a font size that the block editor could handle natively? If it's the latter, you're probably writing code that's either redundant or getting overridden.

Practical Steps for Writing CSS That Actually Sticks

If you're building on a modern WordPress theme and want your styles to actually work, here's a practical approach worth adopting.

Start with theme.json first. Before you open a CSS file, ask whether what you're trying to accomplish belongs in your design token system. Color, typography, spacing, and border settings should almost always start there.

Audit your existing CSS for redundancy. Pull up your style sheet and go through it with fresh eyes. For every rule, ask: is this overriding a block attribute? Is this setting a value that theme.json could handle? You might be surprised how much you can delete.

Use block style variations strategically. WordPress lets you register additional style variations for blocks — like a "card" variation of the Group block. This is a clean way to offer editors styling choices without forcing them to use custom CSS classes or remember arbitrary class names.

Test with the inspector, not just the front end. When a CSS rule seems to have no effect, open DevTools and check whether an inline style is winning the specificity battle. That'll tell you immediately whether you need to rethink the approach or just increase specificity.

Document what your CSS is for. This sounds basic, but in a block-editor world it's more important than ever. A comment explaining that a rule targets a specific pattern edge case or a particular block context will save future-you an enormous amount of confusion.

The Mental Model Shift Nobody Warned You About

Here's the uncomfortable truth: WordPress development in 2024 and beyond requires thinking about styles at two distinct layers. There's the design system layer — handled by theme.json, block presets, and pattern architecture — and there's the behavioral and structural layer, which is where CSS still earns its keep.

Developers who try to do everything at the CSS layer are writing against the grain of how the platform works now. That creates bloated style sheets, specificity wars, and patterns that break whenever a client touches the editor. It also creates the frustrating experience of writing CSS that seems to do nothing.

The block editor isn't perfect. The tooling around theme.json can be clunky, pattern management is still maturing, and there are legitimate pain points in the workflow. But the direction of travel is clear, and getting fluent in the settings-first model is one of the most valuable things a WordPress developer can do right now.

Write less CSS that fights the system. Write more theme.json that feeds it. Your future self — and whoever inherits your project — will thank you.