mymodule { | |
@at-root { | |
.#{&}-header { ... } | |
.#{&}-footer { ... } | |
.#{&}-body { | |
a { ... } | |
span { ... } | |
p { ... } | |
} | |
} | |
} |
.mymodule-header { ... } | |
.mymodule-footer { ... } | |
.mymodule-body a { ... } | |
.mymodule-body span { ... } | |
.mymodule-body p { ... } |
This comment has been minimized.
This comment has been minimized.
How does Sass tell the difference between "mymodule" and a regular HTML tag? |
This comment has been minimized.
This comment has been minimized.
well, don't use a html tag. |
This comment has been minimized.
This comment has been minimized.
I have the same question as @jlong Also, is there any other |
This comment has been minimized.
This comment has been minimized.
This is awesome. |
This comment has been minimized.
This comment has been minimized.
I think Sass schouldn't make any assumptions here and BOTH using a classname Also, Sass simply shouldn't care whether a user chose a base name that also happens to be an html-element name. If someone for whatever reason uses an html element name for his base name/prefix – fine. You're perfectly able to use And OH GOD YES for the feature :) |
This comment has been minimized.
This comment has been minimized.
+2 for @porada proposal |
This comment has been minimized.
This comment has been minimized.
Agree with @porada as well. |
This comment has been minimized.
This comment has been minimized.
+1 @porada |
This comment has been minimized.
This comment has been minimized.
@MarioRicalde, @jlong Sass doesn't tell the difference between @porada We've decided that a bare 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 @function current-module() {
$module: nth(&, 1);
@if str-slice($module, 1, 1) == "." {
$module: str-slice($module, 2)
}
@return $module;
} |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
@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?
|
This comment has been minimized.
This comment has been minimized.
I like the @jlong approach and I was thinking the exact same thing. |
This comment has been minimized.
This comment has been minimized.
Same here, I like the @jlong approach, more easy to use |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 With styles.css: .table {
color: red;
} Then namespace mymod {
@import "styles.css";
} Would compile to .mymod-table {
color: red;
} |
This comment has been minimized.
This comment has been minimized.
Can someone please give another example of how namespacing might be used--thanks @aceofspades, I just would like to see it in another context. |
This comment has been minimized.
It’s great. I wish it worked slightly different, though.
.#{&}
isn’t the most elegant piece of code.