Isolate your CSS once and for all with @scope

Fighting global specificity is a waste of time. Historically, we used BEM or CSS Modules to simulate isolation, but @scope has arrived so the browser can do the heavy lifting for you, without processors or mile-long class names.

How can you protect your components with @scope?

The magic of @scope isn't just that it limits where styles apply, but that it allows you to define a lower boundary (the famous Donut Scoping). This is ideal for components that host dynamic content but shouldn't interfere with their internal styles.

/* Define the upper boundary (.card) and the lower one (.content) */
@scope (.card) to (.content) {
  img {
    border-radius: 12px;
    border: 2px solid var(--hue-brand);
  }

  :scope {
    background: var(--surface-1);
    padding: 2rem;
    display: block;
  }
}

In this example, any image inside .card will have the rounded border, unless that image is inside .content. It’s a native way of saying: "This style belongs to me, but what's inside that container is someone else's territory."

Why does proximity beat specificity?

This is where @scope changes the game. If you have two styles that tie in specificity, the traditional cascade relies on order of appearance. With @scope, Scoping Proximity takes over.

If a component has a dark theme applied via a nearby scope, that style will win over a global light theme, even if the global selector is more complex. It's pure pragmatism injected directly into the browser engine.

Check this principle in action in our Design System or combine it with CSS Layers for total architectural control.

What about performance?

Forget about generating unique hashes at build time or injecting dynamic styles that clutter the DOM. @scope is interpreted directly by the browser. For us in Astro 6, this means we can ship pure CSS and let the client handle isolation with maximum efficiency and 0kb of blocking JavaScript.

References

• MDN: @scope at-rule
• Chrome for Developers: Limit the reach of your selectors