{"id":6091,"date":"2025-06-17T09:26:54","date_gmt":"2025-06-17T14:26:54","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=6091"},"modified":"2026-04-04T16:43:04","modified_gmt":"2026-04-04T21:43:04","slug":"scope-in-css","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/scope-in-css\/","title":{"rendered":"Scope in CSS"},"content":{"rendered":"\n
\n
\n

This is a written adaptation of my talk at CSS Day 2025. It was a lovely event, but I realize life is complicated and not everyone can make it to events like this. There are videos up paywalled at conffab.com<\/a>. I figure this written version can make my points as well.<\/p>\n\n\n\n

If it’s helpful to have the slides, here ya go:<\/p>\n\n\n\n

scope_slides.pdf<\/a>Download<\/a><\/div>\n<\/div>\n\n\n\n
\n
\"Chris<\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
\"A<\/figure>\n<\/div>\n\n\n\n
\n

I hate to break it to ya, but CSS is… mostly scope. The act of writing CSS is to:<\/p>\n\n\n\n

    \n
  1. Write some scope<\/li>\n\n\n\n
  2. Write some styles<\/li>\n<\/ol>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Even something like .cool<\/code> is pretty extreme scoping. It only<\/em> effects elements in the DOM that happen to have that exact <\/em>class. OoooOoo rare.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    It’s easy to think of CSS skill of being about knowing how to accomplish all the fancy styling bits. But the best CSS developers are also talented at knowing where and how<\/strong> to apply those styles. Scope.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Selectors are a big part of scoping, but there are other things in CSS that apply scope like @media<\/code> queries, @support<\/code>, and other at-rules.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Say we need to style a real-world design like this.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    This part we could easily call a .card<\/code> and apply reusable styles accordingly.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Later, a new element comes up that is fairly card-like. Should we re-use the class? We’re at a mental CSS crossroads. The padding is a bit different, the colors are a bit different, there is no border-radius… <\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    … meh. Screw it. Let’s call this one .challenge-card<\/code>. <\/p>\n\n\n\n

    We’ve accomplished scoping with our little ol’ fingers and brain.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    99% of all the CSS scoping I’ve done in my life has been just like the above. Just use a different name and selector in order to avoid unwanted style collisions. Done.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    There are<\/em> problems that can come up here though. And there are tools to help with those problems.<\/p>\n\n\n\n

    But let’s reach for tools when we actually have the problem, not because the theoretical problem exists.<\/em><\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Regular ol CSS is “global” in nature. <\/p>\n\n\n\n

    Maybe your brain keeps thinking of using .card<\/code> as a class name, only to discover it’s already being used. Worse, you write up your styles using that name, it all looks great, and you don’t realize you’ve steamrolled other parts of the site with your new clashing styles. Derp.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Two different developers at different times can choose the same names and selectors and cause issues, possibly without even knowing it. That’s probably the worst and most insidious problem.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    We could call that “The Barstool Problem”. <\/p>\n\n\n\n

    That is, writing CSS that affects styles elsewhere that you didn’t intend.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    If you face problems like this, which I’d say is a reasonable concern as soon as 2 or more people are working on a project, or the project is of Medium\u2122 size or bigger, it may be time to tool the problem away.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    There is stuff in the web platform to help… sort of. We’ll get to that. But let’s do userland tools first.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    One approach to scoping styles is to process the HTML\/CSS\/JavaScript that we write such that the selectors being applied are unique and won’t cause The Barstool Problem.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"Image<\/figure>\n<\/div>\n\n\n\n
    \n

    CSS Modules is interesting in that this kind of scoping is the only<\/em> thing that it does. It’s whole reason for existence is scoping class names.<\/p>\n\n\n\n

    It’s also 10 years old just recently, congrats CSS Modules!<\/p>\n\n\n\n

    I love how it was worked on in 2015 and that’s basically it. Feature complete for 10 years.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Here’s how it works. <\/p>\n\n\n\n

    You write regular CSS (nice!).<\/p>\n\n\n\n

    The CSS that ends up on the page is that class plus some gibberish, which accomplishes the scoping part.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"Diagram<\/figure>\n<\/div>\n\n\n\n
    \n

    How does the HTML know to match to that class? You import the styles in your JavaScript. What you get is an object that maps the class names you wrote to the gibberish ones that will match. <\/p>\n\n\n\n

    That’s it really. So CSS Modules is only relevant in JavaScript-produced markup.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"A<\/figure>\n<\/div>\n\n\n\n
    \n

    No barstools will be kicked over in this situation. If 50 developers all use .card<\/code> as a class name, they won’t clash.<\/p>\n\n\n\n

    In practice, giving the top-most element of the component a class name of root<\/code> is nice because standard conventions mean you don’t have to think too hard about it.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    I also enjoy how CSS Modules is just an idea. Tons of bundler-type applications support it, but they do so by just following the spec of how it should work.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Out in “the real world”, here’s a React component that imports a CSS files that uses CSS modules conventions (which also<\/em> use Sass just for fun, it’s being processed anyway). The className<\/code> is applied. <\/p>\n\n\n\n

    Crucially, this co-locates the styles and the component.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    When you scope and<\/em> co-locate styles, it really lessens the issue of “unused CSS”. All-global CSS tends to grow over time and lead to CSS files that developers are (rightfully) afraid to touch (barstools) and that are essentially wasted bandwidth. <\/p>\n\n\n\n

    Scoped, co-located CSS means it’s less likely there is unused CSS in those files. If the component isn’t used, the CSS doesn’t load at all (typically). <\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Junk the component, junk the styles along with it. No more orphaned styles.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    This style co-location happens in the concept of CSS-in-JS as well. Usually not my favorite approach to CSS, but I do like the idea of keeping the styling job close to the components themselves.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"A<\/figure>\n<\/div>\n\n\n\n
    \n

    I do not think the world is better off because React is unopinionated about styles. We would have been better off if they just had a blessed styling technique. <\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Vue has a blessed styling technique which does scoping and it’s perfectly nice.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    I like how the [data-attribute]<\/code> it adds means you get to keep the exact class you authored too, which won’t change over time, so you’re maintaining nice hooks for people’s user stylesheets.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Svelte also has a blessed styling technique which scopes and it’s fine.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Can the web itself help us with selector scoping? Maybe not exactly like this, but we’ll see. The scoping it traditionally provides is either super loose (just use a different class) or super hardcore.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \"Text<\/figure>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Websites can include other… websites. By way of the venerable <iframe><\/code>, of course. They are fraught with challenges, but they were foundational to the last three companies I worked at, so respect.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Also known as iFrames<\/code>, of course.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"A<\/figure>\n<\/div>\n\n\n\n
    \n

    Designed by Apple in California.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    For real though, you can show web content with them, and there\u2019s no way CSS from the outside will leak in or CSS from inside leak out. But they are a brick wall and not a practical choice just for this purpose alone.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Shadow DOM is also pretty hardcore scoping. Styles that inherit can sneak through a shadow DOM boundary (including custom properties), but little else. This hardcore scoping is largely why it exists.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    The first time I came across the shadow DOM was when I advocated for <use><\/code> in SVG as a better alternative for icons than using icon fonts. When you <use><\/code> another bit of SVG, it clones it into a shadow root and becomes an <svg><\/code> of it\u2019s own.<\/p>\n\n\n\n

    Form elements often use shadow roots to abstract away their UI implementations as well.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"Text<\/figure>\n<\/div>\n\n\n\n
    \n

    We can make our own shadow DOM now with Web Components<\/a>. But bear in mind you don\u2019t have to. Keeping to the light DOM can be awfully nice<\/a>.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"Code<\/figure>\n<\/div>\n\n\n\n
    \n

    As we\u2019ve covered, scoping can be kinda great, and the fact that we can opt-in to it in Web Components is nice. It\u2019s a one-liner to make a custom element have a shadow DOM.<\/p>\n\n\n\n

    Here, I\u2019m injecting a <style><\/code> tag into that shadow DOM, which will inherently be scoped.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"An<\/figure>\n<\/div>\n\n\n\n
    \n

    The selector used in that style tag is simply: button<\/code>. And notice that only<\/em> the <button><\/code> that is within the Web Component is styled with it, not the <button><\/code> outside of it. Sometimes that\u2019s exactly the goal.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"Text<\/figure>\n<\/div>\n\n\n\n
    \n

    Imagine not just a button but an entire system of components that only look the way they do because of baked-in scoped styles on themselves. No worries of their styles affecting other elements, or, for the most part, other styles coming in and screwing things up.<\/p>\n\n\n\n

    Sounds pretty good for design systems right?<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    That\u2019s not just an \u201coh yeah, hmmm, maybe that could work\u201d situation. Pretty much all the major design systems ship with shadow DOM scoping.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \"Image<\/figure>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    When we talk about styling via classes, there used to be several different names of projects we could point to, but these days let\u2019s be real: it\u2019s Tailwind<\/a>.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Since you aren\u2019t writing classes or other selectors to do styling in Tailwind, the styles you are applying are already scoped.<\/p>\n\n\n\n

    Even if it\u2019s not the main reason people choose a tool like Tailwind, it is a potential benefit.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Even if I admit the approach isn\u2019t for me, Tailwind does have some objectively good characteristics. One being that the CSS output is generally a good bit smaller than \u201cnormal\u201d because of the de-duplication. Perhaps the HTML is a bit bigger, but it\u2019s CSS that is more of a blocking resource, so it\u2019s probably a net-win.<\/p>\n\n\n\n

    I mostly don\u2019t like it because it feels like you need to know CSS anyway, and now you\u2019ve got to use this leaky abstraction on top of it, and when I\u2019ve tried it I feel like I\u2019m not buying much.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    CSS actually has a thing called @scope<\/a><\/code> now. Props to Miriam Suzanne for brainchilding and shepherding it.<\/p>\n\n\n\n

    My knowledge of @scope<\/code> is just from playing around and reading the work of people who write on MDN and for Google\u2019s sites and fellow bloggers. So thank you to everyone who makes technical content. I probably read it.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    If you\u2019re wondering about browser support, basically the story is it\u2019s waiting for Firefox, which already has it under a flag. It\u2019s in Interop 2025<\/a>, so it shouldn\u2019t be too long.<\/p>\n\n\n\n

    I\u2019d say it doesn\u2019t progressively enhance terribly well, so chill on it a sec.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    The first glance at the syntax had me feeling it left, uh, something to be desired.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Here’s some perfectly reasonable HTML and some perfectly reasonable CSS to go with it.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Rather than writing .card {}<\/code> we could write @scope (.card) {}<\/code> and it’s… almost exactly the same functionality just more characters to type. <\/p>\n\n\n\n

    At least, that was my initial impression.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    For the record, we should be able to test the support of it like this. But we can’t. Because at-rule()<\/code>, while agreed upon<\/a>, isn’t implemented anywhere yet. When it is, it’s likely any browser that supports it will also support @scope<\/code> so this will probably never be a useful combo.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    While that very basic demo of the syntax isn\u2019t dripping with usefulness, there are some somewhat niche things that @scope<\/code> can do that do have their uses.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \"A<\/figure>\n\n\n\n
    \n
    \n
    \"Screenshot<\/figure>\n<\/div>\n\n\n\n
    \n

    Nicole Sullivan blogged scope donuts<\/a> in 2011 and it\u2019s just now a thing. So that\u2019s a lesson for you. If you want something in the web platform, make a good case for it then wait 15 years.<\/p>\n\n\n\n

    Donut scoping is a way to select an element and allow descendent selectors as usual, up until a point you specify<\/em> where descendent selectors no longer apply.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    I always think of element that contain body copy as a use case. Like chunks of converted markdown are special little bubbles with their own styles and you want to prevent other styles leaking int there that you don\u2019t want.<\/p>\n\n\n\n

    Here\u2019s an example of an article on WIRED where we can clearly see some body copy (and non-body copy).<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Links within body copy should be underlined. And they do that. Good job WIRED.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    It\u2019s arguable, but links in some other places may not need to be underlined as there is enough visual affordance that they are links anyway, like in navigation or article cards.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    A common way to handle links-in-some-areas vs not-in-others is to let links be underlined by default, then select areas to remove them and remove them.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    The reverse of that is to remove link underlines everywhere, and re-apply them places you want them, like in body copy content.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Donut scoping gives us a rather elegant way to express this idea. Remove links everywhere except within element with a class name of content<\/code>. That reads decently well to me.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Donuts can have more than one hole, depending on what you\u2019re doing in the DOM.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"A<\/figure>\n<\/div>\n\n\n\n
    \n

    Massive upheaval in how we write CSS? No. But it\u2019s a nice little niche tool and CSS is better for having it.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \"Graphic<\/figure>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Proximity scope is rather amazing in that it\u2019s an entirely new \u201clevel\u201d by which the browser decides which CSS rules to apply. We\u2019ll see that in a moment as we look at a basic use case.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    I wouldn\u2019t say it\u2019s ultra common, but one way to implement color themes is to use class names on wrapper elements that signify which theme is to be used there.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Say we have a dark and a light theme, those themes have more jobs to do that set one background-color<\/code> and one color<\/code>. It might change lots<\/em> of stuff.<\/p>\n\n\n\n

    Think about link colors. Blue links may need to be lighter on a dark color and darker on a light color. So we\u2019re expressing that here with an oklch()<\/code> color that adjusts the lightness.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n

    Themes could<\/em> be nested. Again maybe not ultra-common, but if they are just classes, it could be done. Imagine an entire page in light mode, but the footer swaps to dark mode as it\u2019s a nice look. That might end up nested if we\u2019re talking like\u2026<\/p>\n\n\n

    <body<\/span> class<\/span>=\"theme-light\"<\/span>><\/span>\n  ...\n  <footer<\/span> class<\/span>=\"theme-dark\"<\/span>><\/span>\n  ...<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre><\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    If we define our themes as single classes one after another, we might run into problems. Each theme will have an indentical specificity, so the last<\/em> one declared will be the \u201cmost powerful\u201d because of source order.<\/p>\n\n\n\n
    See the links now. Those links are technically within an element with theme-light<\/code> and<\/em> theme-dark<\/code>. But theme-light<\/code> is \u201cmore powerful\u201d as it\u2019s declared last, and thus we get the wrong color.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    Scope can help here. By replacing those theme selectors with like @scope (.theme-dark) {}<\/code> now proximity scoping<\/strong> kicks in.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"A<\/figure>\n<\/div>\n\n\n\n
    \n
    Proximity is less powerful than specificity of selectors, but it\u2019s more<\/em> powerful than source order. That\u2019s a little weird to wrap your mind around at first, I think. But this simple demo hopefully helps.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    Because the theme-light<\/code> class is \u201ccloser\u201d in the DOM to those links, it will \u201cwin\u201d. Source order doesn\u2019t matter here anymore, it matters which of the otherwise-equal selectors has higher proximity.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    Big sea change in CSS? Again, no, but CSS is better off for having this niche tool.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    Anytime source order might be a concern, it\u2019s possibly proximity styling can step in to help.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    Imagine variation classes on a \u201ccard\u201d element. If the variation classes have the same specificity as the base class, the worry is the base class will override what the variation is doing.<\/p>\n\n\n\n
    This could be the case in systems that bundle CSS in ways you don\u2019t fully understand, or load CSS on demand in ways that even user actions may affect the order.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    <\/div>\n<\/div>\n\n\n\n
    \n
    <\/div>\n\n\n\n
    <\/div>\n<\/div>\n\n\n\n
    \"A<\/figure>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    See this bit of HTML. Two <div><\/code>s, one of them with a <style><\/code> tag inside and one without.<\/p>\n\n\n\n
    Inside that <style><\/code> tag we immediately see an @scope<\/code> at-rule, with no parens at all. What is the scope then? Used like this, the scope is the parent element of the <style><\/code>, so the <div><\/code> parent. From there, we can select that <div><\/code> or any descendants.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    All the sudden we have a way to style from just one particular element downwards without even having to name it order use any selector at all.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    I said the web platform doesn’t really have selector scoping help, but this is basically that. This is probably as close as we’ll ever get. <\/p>\n\n\n\n
    It feels like a pretty powerful concept to me. <\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    What if we just did this “instead” of linking up CSS files and finding scoping solutions there? Maybe this is just how we style most everything on the page. Perhaps from the “component” level on down. Is that a reasonable thing to do?<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"A<\/figure>\n<\/div>\n\n\n\n
    \n
    I did attempt to build a demo<\/a> with 1,000 cards where one page loaded CSS “regularly” with one stylesheet that applies to all the cards. Then another page where each of the 1,000 cards has a @scope<\/code>-d <style><\/code> block within it. <\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"\"<\/figure>\n<\/div>\n\n\n\n
    \n
    You’d think the 1,000 extra <style><\/code> blocks would be awful for performance, but, quite weirdly, the difference was almost undetectable. I think this was a poor test though<\/strong> as there was so much of the exact same code the browser was probably great at optimizing it. A better test would be tons of totally different components and include interactivity.<\/p>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \"A<\/figure>\n<\/div>\n\n\n\n
    \n
    At a minimum, sprinkling in scoped styles into the DOM where you just want a bit of styles that will never “leak out” and screw up anything else is super cool<\/em>. <\/p>\n<\/div>\n<\/div>\n\n\n\n
    \"Slide<\/figure>\n\n\n\n
    \n
    Cheers!<\/p>\n\n\n\n