 <p>Yes, <code>@at-root</code> will do what you want.</p> <p>However, I question the premise of your question.</p> <p>First, let's assume you really want to write <code>#article { #article-inner {</code>. For this, SASS will generate the code <code>#article #article-inner {</code>. You want it to generate <code>#article-inner {</code>. But why? Presumably you are concerned about the possibly lower efficiency of parsing, downloading, or applying the former as compared to the latter. Actually, though, any differences in efficiency would be <strong>miniscule to non-existent</strong>.</p> <p>Second, I wonder why you think nesting the rules is "easier to read". Actually, to me it's <em>harder</em> to read. Presumably you think following the structure of the HTML is going to make it easier to read. Actually, following the structure of the HTML makes your CSS brittle. In computer science terms, this is called "coupling", generally considered a Bad Thing; in this case, you are coupling your HTML too tightly to your CSS. For instance, if for whatever reason <code>#article-inner</code> moved, or appeared somewhere else, then, even though the ID matched, your rule would stop working. </p> <p>Experienced SCSS coders make very light use of its nesting capabilities. Instead, they write rules that are <strong>orthogonal</strong> to the HTML, which can be combined to create a number of styling effects, without being slavisly bound to the hierarchical structure of the HTML. Good SCSS coders I know limit themselves to nesting in the case of things like <code>.class { color: red; &amp;:hover { color: blue; } }</code>, or in other cases to one level at most. In your case, if you have to use <code>@at-root</code> to do what you want, you have now actually made your code less readable in the name of readability.</p> <p>SCSS is not going to live forever. Some day CSS will handle much of what it now does for us, including variables. Some shops are already moving away from SASS, with its ugly, verbose macros, mixins, hard-to-maintain features like <code>@extend</code>, and excessive nesting, back to raw CSS or forward to more modern preprocessors like suitCSS. We need SASS less and less for vendor-prefixing; other preprocessors support modularized, automated vendor prefixing tools. For all these reasons, therefore, it's not unreasonable when writing SCSS today to consider the potential that your code might need to be ported <em>away</em> from SCSS sometime in the future. That would indicate you should avoid using lots of SCSS-specific features when they're not really necessary, such as the nesting in your case.</p> <p>If you want readability, add comments, which you should be doing anyway.</p> <pre><code>#article { ... } /* The `#article_inner` element is inside `#article`. #article_inner { ... } </code></pre> <p>More generally, I would question an ID-based approach to writing CSS. Presumably you intend to specify a bunch of properties on <code>#article-inner</code>, like font size, background, padding, or whatever. I've seen CSS where there are a dozen properties or more. What is the point? You might as well just write the properties in a <code>style</code> attribute directly on the element; at least then, you'd only have one file (the HTML) to manage. Instead, knowledgeable CSS designers create small, utility-like classes that can be applied to many elements. For instance, they might define a <code>PaddedGrayBox</code> class, that handles the padding and background. Then, they write in their HTML</p> <pre><code>&lt;div id='article-inner' class='PaddedGrayBox FloatRight...'&gt; </code></pre> <p>Now <strong>this</strong> is more readable. Someone looking at the HTML can immediately see what kinds of styling are being applied. If you take this approach consistently, you may find that you are able to do away with using IDs altogether, although I know that would be quite a departure for jQuery-oriented programmers who believe that doing <code>$('id')</code> (or <code>getElementById</code>) on every other line is the core of JavaScript programming.</p>