The Scoping We Needed – Frontend Masters Journal
Uncategorized

The Scoping We Needed – Frontend Masters Journal

author
2 Min Read

I’ve dedicated much of my career to exploring CSS scope, even presenting on it recently, as documented here. This came on the heels of the introduction of @scope in CSS, naturally part of the CSS scope narrative.

I’m not entirely against @scope, but I’m okay admitting it disappoints me. It has three uses, all of which I find quite niche:

  1. Donut scoping
  2. Proximity specificity
  3. DOM blasters

I discussed these in my presentation. They have their applications, but once again, they’re niche.

The kind of scoping I desire in CSS is akin to what tools like in .vue files or Svelte components offer, and more broadly, what CSS modules provide.

I want to write:

.card {
}

And have it transform into something like:

[data-style="apio087df"] {
}

(With the attribute applied to my HTML to ensure the new selector functions.)

I want this transformation to avoid conflicting class names. Ideally, it’s something I wouldn’t have to ponder.

I don’t require this in every project I undertake; I want it for expansive projects with numerous components and frequent style modifications over the years.

To me, this is scoped styling.

CSS modules already provide this, and that’s excellent. But I appreciate it when the web platform assists us with tasks we’d typically rely on build processes and tools for. @scope didn’t deliver this.

Alternatively, ensuring all your class names are unique suffices for most projects and has been possible since the inception of HTML and CSS.

If name scoping is the extent of our approach, that’s okay. I can work with that.


But wait, name-only containers?

I read in Safari 26.4 release notes about Safari’s support for name-only containers. Like this:


.sidebar {
  container-name: sidebar;
  container-type: inline-size;
}

@container sidebar {
  .card {
    padding: 1rem;
  }
}

No conditions? Isn’t a container’s main purpose styling based on conditions (like most often, its width)?

Not if we want this solely for scoping purposes! (!!!)

Components typically already have unique names.

Components generally reside in folders, which must have distinct names, enforcing uniqueness.


Consider three components from a design system (ds):

Styles in Components

Each of them has styles bundled into global CSS:

  • ds-card.css
  • ds-article.css
  • ds-header.css

This isn’t about shadow DOM or web

You might also like