1. Home
2. web
3. CSS Scoped Styles: @scope and Encapsulation Strategies

CSS scoping has always been a challenge. Styles cascade globally by default, meaning a selector in one component can unintentionally affect elements in another. Over the years, developers have adopted naming conventions, build-time tools, and full DOM isolation to solve this. The newest addition to this toolkit is the CSS @scope at-rule, which introduces proximity-based cascade control. This article compares all major scoping strategies and helps you choose the right one.

The @scope At-Rule

The CSS Scoping Module Level 1 introduces @scope, which limits styles to a specified root element and its descendants. Unlike naming conventions, this is enforced by the browser.

@scope (.card) {
  .title { font-size: 1.25rem; font-weight: 600; }
  .body { padding: 1rem; }
}

The key innovation is scope proximity: styles scoped closer to an element take precedence over styles scoped further away, regardless of selector specificity. You can also define scope limits to restrict how far down the tree the styles apply.

@scope (.card) to (.card__footer) {
  .link { color: blue; }
}
/* Applies only within .card but stops before .card__footer */

This avoids the nested card problem — a card inside another card won’t inherit the outer card’s scoped styles. @scope is supported in Chrome 118+, Safari 17.4+, and Firefox 128+.

Shadow DOM

Shadow DOM provides the strongest form of encapsulation. Styles, markup, and behavior are fully isolated within a shadow root — no CSS can leak in or out.

class MyCard extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({ mode: "open" });
    shadow.innerHTML = `
      <style>
        .title { font-size: 1.25rem; }
      </style>
      <div class="title">Hello</div>
    `;
  }
}
customElements.define("my-card", MyCard);

Shadow DOM is essential for distributed widget libraries and design system primitives where absolute isolation is required. However, it adds runtime overhead per instance and complicates cross-boundary styling with ::part() and ::slotted(). For most application components, the isolation level of @scope or CSS Modules is sufficient.

CSS Modules

CSS Modules generate locally scoped class names at build time, preventing collisions without runtime cost.

/* card.module.css */
.title { font-size: 1.25rem; }
.body { padding: 1rem; }

import styles from "./card.module.css";
function Card() {
  return <div className={styles.card}>
    <h2 className={styles.title}>Title</h2>
  </div>;
}

The build tool transforms .title into a unique name like .card_title_3kl4s. Benefits include zero runtime overhead, TypeScript integration via auto-generated type definitions, and composable styles with composes. The limitation is that only class selectors are scoped — element and attribute selectors remain global.

BEM and Naming Conventions

BEM (Block Element Modifier) prevents conflicts through disciplined naming: .block__element--modifier. It requires no build tooling and is immediately understandable.

<div class="card card--featured">
  <h2 class="card__title">Title</h2>
  <p class="card__body">Content</p>
  <button class="card__btn card__btn--primary">Action</button>
</div>

BEM scales poorly in large codebases because there is no actual encapsulation — cascade leaks still happen, and class names become unwieldy with deep nesting. BEM remains practical for projects without a build step or for legacy codebase migrations.

Practical Scoping Strategies

A pragmatic hybrid approach works best: use CSS Modules for class-level scoping in component files, add @scope for cascade management within those components, adopt Shadow DOM only for reusable widget libraries, and keep BEM for global utility classes. The @scope at-rule represents a paradigm shift, bringing browser-enforced scoping to CSS for the first time and making cascade management dramatically simpler for everyday component styling.