{"id":9223,"date":"2026-04-07T09:15:10","date_gmt":"2026-04-07T14:15:10","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=9223"},"modified":"2026-04-07T10:21:31","modified_gmt":"2026-04-07T15:21:31","slug":"name-only-containers-the-scoping-we-needed","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/name-only-containers-the-scoping-we-needed\/","title":{"rendered":"Name-Only Containers: The Scoping We Needed"},"content":{"rendered":"\n

I’ve done my time thinking about scope in CSS. I’ve done it my whole career, and did a presentation on it recently that I wrote up in full here<\/a>. That was on the heels of @scope<\/code> becoming a thing in CSS<\/a>, which is, naturally, a part of the scope in CSS story. <\/p>\n\n\n\n

I don’t entirely dislike @scope<\/code>, but I guess I’m comfortable saying I’m disappointed in it. It can do three things, all of which I find quite<\/em> niche:<\/p>\n\n\n\n

    \n
  1. Donut scoping<\/li>\n\n\n\n
  2. Proximity specificity<\/li>\n\n\n\n
  3. DOM blasters<\/li>\n<\/ol>\n\n\n\n

    I covered these<\/a> in my talk. They have their uses, but again: niche<\/em>. <\/p>\n\n\n\n

    The kind of scoping that I want in CSS is the kind that we’ve been given by tools like <style scoped><\/code> in .vue<\/code> files and Svelte components, and more broadly, what CSS modules does<\/a>. <\/p>\n\n\n\n

    I want to write:<\/p>\n\n\n

    .card<\/span> {\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    And have it turned into something like:<\/p>\n\n\n
    [data-style=\"apio087df\"<\/span>]<\/span> {\n  \/* Or, .card-apio087df *\/<\/span>\n  \/* But I kinda like the data-attribute approach\n     better because it leaves the original class alone *\/<\/span>\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    (And have that attribute applied to my HTML so the new selector works.)<\/p>\n\n\n\n
    The reason I want that is that I don’t want to worry about a class name I’m writing conflicting with an existing class. I just don’t want to think about it. Ever, ideally.<\/p>\n\n\n\n
    I don’t need this on every<\/em> project I touch; I want<\/em> it on large-scale projects with lots of components and a high number of style changes maintained over many years.<\/span><\/p>\n\n\n\n
    To me, that’s a scoped style.<\/strong><\/p>\n\n\n\n
    I already get it with CSS modules, and that’s fine. But I’m a big fan when the web platform steps in and helps us do things we’d otherwise use a build process and tooling to do. That’s what we didn’t get with @scope<\/code>.<\/p>\n\n\n\n
    Another alternative is just making all your class names unique. This works on the vast majority of projects and requires no technology we didn’t have pretty much since HTML and CSS began life.<\/p>\n\n\n\n
    If class name scoping is all you or I ever do, that’s OK. I can live with that. <\/p>\n\n\n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n
    But wait, name-only containers?<\/h2>\n\n\n\n
    I read in the Safari 26.4 release notes<\/a> that Safari is now supporting name-only containers. Like this:<\/p>\n\n\n
    \/* Name a container *\/<\/span>\n.sidebar<\/span> {\n  container-name<\/span>: sidebar;\n  container-type<\/span>: inline-size;\n}\n\n\/* Write styles with that name only, no conditions *\/<\/span>\n@container<\/span> sidebar {\n  .card<\/span> {\n    padding<\/span>: 1rem<\/span>;\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    No conditions? Isn’t the whole point of a container to style based on conditions (like, 98% of the time, being how wide it is)?<\/p>\n\n\n\n
    Well, not if the only effect we want from this is scoping! (!!!)<\/p>\n\n\n\n
    Components typically already have unique names.<\/h2>\n\n\n\n
    Because components typically live in folders and folders have to have different names, components already have a forced uniqueness constraint.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Let’s just consider three. Here’s three design system (ds) components:<\/p>\n\n\n\n
      \n
    • <ds-card><\/code><\/li>\n\n\n\n
    • <ds-article><\/code><\/li>\n\n\n\n
    • <ds-header><\/code><\/li>\n<\/ul>\n\n\n\n
      Styles in Components<\/h2>\n\n\n\n
      Each of them has styles that get bundled into global CSS:<\/p>\n\n\n\n
        \n
      • ds-card.css<\/li>\n\n\n\n
      • ds-article.css<\/li>\n\n\n\n
      • ds-header.css<\/li>\n<\/ul>\n\n\n\n
        We’re not talking shadow DOM and web components here, I’m talking very generally about any design system of components, regardless of framework. <\/p>\n\n\n\n
        Both a card and an article can very easily have a title. It’s entirely reasonable to write a class like:<\/p>\n\n\n\n
        \n
        \/* ds-card.css *\/<\/span>\n.title<\/span> {\n  background<\/span>: rebeccapurple;\n  color<\/span>: white;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre><\/div>\n\n\n\n
        \/* ds-article.css *\/<\/span>\n.title<\/span> {\n  font-weight<\/span>: 300<\/span>;\n  letter-spacing<\/span>: -0.01em<\/span>;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre><\/div>\n<\/div>\n\n\n\n
        Just some contrived styles there. Those will overlap and both apply because of the identical class names in use. <\/p>\n\n\n\n
        Usually<\/em> that’s not what we want. Usually<\/em> we avoid this by just career-long muscle memory of knowing this and perhaps some BEM methodology or nesting.<\/p>\n\n\n
        ds-card<\/span> {\n  .title {\n    \/* Title styles unique to the card *\/<\/span>\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        That’s artificial specificity boosting just to avoid future trouble. Not the end of the world, but not ideal.<\/p>\n\n\n\n
        It feels nicer not to think about it, which is what we get in a CSS modules approach. The styles can’t clash because they are programmatically randomized. And we don’t have to nest either, meaning we’re not bumping up specificity just for scoping.<\/p>\n\n\n\n
        Scoping Styles in Components<\/h2>\n\n\n\n
        Let’s say we use the name of the component as the CSS container-name<\/code> for every component.<\/p>\n\n\n
        ds-card<\/span> {\n  container-name<\/span>: ds-card;\n}\nds-article<\/span> {\n  container-name<\/span>: ds-article;\n}\nds-header<\/span> {\n  container-name<\/span>: ds-header;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        Now in the stylesheet for each of those components (which is again, probably bundled and put into global scope like regular CSS).<\/p>\n\n\n
        @container<\/span> ds-card {\n\n}\n@container<\/span> ds-article {\n\n}\n@container<\/span> ds-header {\n  \n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        Now I can do literally anything I want<\/em> inside those @container<\/code> blocks and it will not globally conflict.<\/p>\n\n\n
        @container<\/span> ds-card {\n  .title<\/span> {\n    background<\/span>: rebeccapurple;\n    color<\/span>: white;\n  }\n}\n@container<\/span> ds-article {\n  .title<\/span> {\n    font-weight<\/span>: 300<\/span>;\n    letter-spacing<\/span>: -0.01em<\/span>;\n  }\n}\n@container<\/span> ds-header {\n  \n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        No conflicts there. Same class name, but scoped inside the relevant containers.<\/p>\n\n\n\n
        That’s it! That’s the scoping power we want. <\/p>\n\n\n\n
        And I’m fairly certain… no side effects. The WebKit blog post uses a container-type: inline-size<\/code>, which would have side effects, but in my testing, that doesn’t seem necessary.<\/p>\n\n\n\n
        Demo<\/h2>\n\n\n\n
        Name-only container styles I belive are only support in Safari 26.4+, so here’s hoping for broader support soon. <\/p>\n\n\n\n