Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free
,

Cover Block Gotchas: When Your CSS Loses to an Inline Style

Field Note #106
🔬 Generalized 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience
You write a clean CSS rule. You’re sure it’s correct — right selector, right property, no typos. You save, clear cache, refresh… and nothing changes. The block stubbornly keeps doing what it was doing before you touched it.
Before assuming your CSS is broken, check one thing first: is the value you’re fighting sitting in an inline style attribute on the block itself?

Why this happens
WordPress’s Cover block (and several others) frequently writes certain properties — min-height, aspect-ratio, padding — directly into the block’s HTML as an inline style, not into a stylesheet. This happens whenever you set those values through the block’s own sidebar controls in the editor.
Inline styles sit at a different, much higher specificity level than almost anything you write in a regular CSS file — including rules marked !important in some cases, since inline style plus !important still generally wins over an external stylesheet’s !important. Your external CSS isn’t wrong; it’s just structurally outranked before it ever gets a chance to apply.

This is especially common with:
min-height — set via the Cover block’s height control, often locking a section to something like 700px regardless of what your CSS says
aspect-ratio — set when an image’s aspect ratio is locked to “Original” in the block’s media settings, which can fight any CSS trying to make it responsive or full-bleed
Custom padding — added through the block’s spacing controls, sitting as inline padding-top/padding-bottom even when you thought you cleared it.

How to confirm it
Inspect the element (right-click → Inspect), and look at the actual HTML tag in the Elements panel — not the Styles panel. If you see style=”min-height: 700px; aspect-ratio: 4/3;” sitting directly on the <div>, that’s your answer. No CSS override will feel like it’s “not working” — it’s working, it’s just losing a specificity fight it was never going to win on its own.

The fix
You have two real options:
Fix it at the source. Go back into the block editor, select the block, and clear the value directly in its own sidebar controls (set height back to default, unlock the aspect ratio, remove custom padding). This removes the inline style entirely — cleanest fix, no override needed.
Force your override to win. If you genuinely need CSS to control it (for a responsive rule the block editor’s UI can’t express), add !important — but confirm it’s actually being applied by checking that the inline style itself doesn’t also carry !important, which does happen with some theme/plugin-injected styles.

How to avoid it next time
Whenever you set height, aspect ratio, or spacing through a block’s built-in sidebar controls, know that you’re not just changing “how it looks in the editor” — you’re baking a permanent inline style into that block’s markup. If you’re planning to also manage that property through your own CSS (for responsiveness, or consistency across many blocks), it’s usually cleaner to leave the block’s own control at its default and do all of the sizing work in your stylesheet instead.

Tagged in :

,

More from the field