0_namespacing.scss

mymodule {
  @at-root {
    .#{&}-header { ... }
    .#{&}-footer { ... }
    .#{&}-body   {
      a          { ... } 
      span       { ... } 
      p          { ... } 
    }
  }
}

1_namespacing_output.css

.mymodule-header { ... }
.mymodule-footer { ... }
.mymodule-body a { ... }
.mymodule-body span { ... }
.mymodule-body p { ... }

+1 @porada

@MarioRicalde, @jlong Sass doesn't tell the difference between mymodule and an element selector. To Sass, this is just an element selector -- albeit, one that browsers would ignore if it were to become a selector in the css file.

@porada We've decided that a bare & in a selector must always resolve to a valid selector. The only way to accomplish this is to limit & to being used wherever an element selector can be used. We have always allowed more complex selector construction using interpolation (#{}). Interpolation in a selector allows access to SassScript -- the syntax for which is not compatible with selectors as SassScript was designed to be used in a value context. By exposing & to SassScript we now have the capability to manipulate the selector context in interesting and arbitrary ways.

This example is exceedingly simple, there are a number of examples working with modules where you need to do arbitrary manipulation of the selector context. For instance this source that uses some nested selectors would not be able to work like you suggest as Sass doesn't really understand what you're concept of a "module" is. Instead, you can teach it what a module is according to your convention like so:

@function current-module() {
  @return nth(&, 1);
}

mymodule {
  @at-root {
    .#{current-module()}-header { ... }
    .#{current-module()}-footer { ... }
    .#{current-module()}-body   {
      a          { ... } 
      span       { ... } 
      p          { ... }
      form       {
        button.#{current-module()}-button { ... } }
    }
  }
}

And this would generate CSS like:

.mymodule-header { ... }
.mymodule-footer { ... }
.mymodule-body a { ... }
.mymodule-body span { ... }
.mymodule-body p { ... }
.mymodule-body form button.mymodule-button { ... }

Alternatively, if you wanted to support having your module to be a classname you could implement the current-module() function like this:

@function current-module() {
  $module: nth(&, 1);
  @if str-slice($module, 1, 1) == "." {
    $module: str-slice($module, 2)
  }
  @return $module;
}

Note: this is a feature that has been long-requested and we think we've found a very simple and consistant way of dealing with myriad use cases. For the long, sordid history please read sass/sass#286 and some of the related issues.

@chriseppstein Seems like what you are saying is that you'ved added a new construct (@at-root) for busting out of whatever nesting you are in and you've given SassScript access to the & operator. This allows for a more powerful way of constructing namespaced CSS, but doesn't really add a first class "module" concept. Am I following you?

What is the benefit of this approach over something more like the following?

$module-name: "mymodule";

.#{$module-name}-header { ... }
.#{$module-name}-footer { ... }
.#{$module-name}-body   {
  a          { ... } 
  span       { ... } 
  p          { ... }
  form       { button.#{$module-name}-button { ... } }
}

I like the @jlong approach and I was thinking the exact same thing.

Same here, I like the @jlong approach, more easy to use

Sass doesn't enforce a particular way of writing CSS and we try to provide approaches that feel natural to develop with. The definition of a "CSS module" doesn't exist in any sort of formal way and neither will it in Sass. When we develop a first class module concept it will be for organizing sass files to ensure namespace collisions can be managed. Feel free to use the approach that @jlong has suggested. It works now. However, many people have wanted a way to use the stylesheet context to define their concept of a module and that is what we are aiming to provide here.

Please keep in mind that these feature can be used within mixins that accept content blocks, etc. So an "@include module($name) { ... } " concept could be defined very easily. I think we will quickly find some very nice ways to create useful abstractions with this set of features. And as I have pointed out elsewhere, the @at-root directive and script access for & have benefits beyond just modules.

Has there been any discussion to do something more unobtrusive? For me, the value of namespacing comes in when integrating, where it's not possible or edit and maintain the source. For example, bootstrap and foundation both use .table which to me is too generic.

With styles.css:

.table {
  color: red;
}

Then

namespace mymod {
  @import "styles.css";
}

Would compile to

.mymod-table {
  color: red;
}

Can someone please give another example of how namespacing might be used--thanks @aceofspades, I just would like to see it in another context.