Scoped CSS, using the @scope at-rule, opens up new ways to keep CSS with the HTML it styles. It’s a game-changer for post authors who otherwise struggle to find ways to have CSS apply to their own elements and nobody else’s. On the other hand, @scope is only sometimes potentially useful for theme authors, custom block developers, and block-pattern authors.
If you’re keeping up with what’s new in CSS, you’ve probably heard of the @scope rule. @scope gives you a new way to limit what your CSS applies to, and it’s been available in all main browsers since December of 2025.
Existing work in CSS management
There are only two hard things in computer science: cache invalidation and naming things
You’re probably familiar with CSS methodologies like BEM to help you manage your CSS, but BEM runs headlong into one of the two hard problems in computer science — naming things. If you go all-in on BEM — like we have — you will be thinking up a lot of different names. On the other hand, “not having to think up a lot of names” is a huge selling point for systems like Tailwind.
Scoped CSS promises a better way.
You can use scoped CSS in two ways:
- in your normal CSS files (or maybe in a
<style>element in<head>), along with your normal rules. I’ll call this stylesheet@scope. - using inline styles, right above the HTML it affects. I’ll call this DOM-nested scope.
(Oddly enough, there isn’t a standard pair of names for these two ways to use @scope, as far as I can tell.)
Stylesheet @scope tends to be discussed the most. In this post, I’ll focus on DOM-nested @scope because that’s more interesting for WordPress development.
For post authors: get real CSS inside a post
Generally, the best use case for DOM-nested @scope CSS is for people who want moderately complicated style in the body of a post. Have a look at this table that would be irritating to recreate with just style attributes:
<table>
<style>
@scope {
td:nth-child(3) { font-weight: bold; }
}
</style>
<thead>
<tr>
<th>Theme</th>
<th>Vibe</th>
<th>Best for</th>
<th>Signature colors</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Adrenaline</th>
<td>High-octane, trail-to-summit, gear-and-guide ready</td>
<td>Adventure outfitters, guiding services, gear shops</td>
<td>Hazard orange, midnight blue</td>
</tr>
<tr>
<th scope="row">Shaka</th>
<td>Laid-back, sun-bleached</td>
<td>Surf schools, beach rentals, coastal cafés</td>
<td>Pacific teal, lifeguard red, driftwood brown</td>
</tr>
<tr>
<th scope="row">BuildPress Landscape</th>
<td>Earthy and practical with crisp negative space</td>
<td>Landscapers, lawn-care crews, hardscape contractors</td>
<td>Fairway green, garden-bed brown</td>
</tr>
</tbody>
</table>
Would you want to add in style="font-weight: bold" for every single third item in the list? After having tried three or four other similar highlighting strategies? Me neither.
For theme authors and custom block developers: a questionable sidegrade from BEM
If you control your product’s stylesheet and its build pipeline, the utility of DOM-nested @scope drops down to “about as useful for you as for most everyone else who writes CSS”. If you use BEM or Tailwind already, you might as well stick with it.
What’s more, if one of your clients wants to override just your elements for some weird reason, crafting non-brittle selectors is much easier if, say, you put in your company name and theme name as part of the block name (the B of BEM) like I’ve seen.
For block-pattern authors: useful if you’re not ready to depend on WordPress 7 yet
In WordPress 6 and earlier, Block patterns can’t add anything to <head>. this means the only options are inline style attributes, a companion plugin, or a <style> element in a Custom HTML block. DOM-nested @scope can be useful here.
WordPress 7’s per-block-instance Custom CSS field covers most of these cases more cleanly. However, DOM-nested @scope is still useful if you have a pattern with styling that spans multiple blocks. If the wrapper needs to drive a transform on an inner Quote block on hover, or if the same --accent has to land on three different children, one <style> inside a Custom HTML block at the top of the pattern can coordinate all of it.
To sum up
How useful DOM-nested @scope is for you and your WordPress work depends a lot on what you’re doing.
If you’re writing posts and want to style something without breaking anything else, DOM-nested @scope is super useful. If you’re writing themes or custom blocks, it’s a sidegrade at best. If you’re writing block patterns, it’s useful if you don’t want to require WordPress 7 or if you want to control styling of multiple blocks that might be descendants of what you’re doing with the block pattern.
