Kind of. Within any sass file, you would only be able to define top level mixin. But those imported mixins will be scoped to the imported context.
The scoping rules will be the same as for variables. I'm still thinking about whether mixins defined via an imported context would overwrite (like variables) or hide any previous definition of that mixin. I'm leaning towards hiding... chris On Wed, Dec 16, 2009 at 2:49 PM, Jacques Crocker <[email protected]> wrote: > Awesome. Will part of this change allow us to define nested mixins as well? > > On Dec 16, 2009, at 2:32 PM, Chris Eppstein wrote: > > Nathan and I did chat and agreed to re-introduce the nested import > functionality. Such files will need to be 100% valid on their own, even if > they are only ever imported. This change has to be done right, with proper > variable and mixin scopes, etc. Also, new test cases need to be written. > > The reason I became sold about this feature was actually for a whole > different reason than was mentioned: It becomes an effective way for users > to manage the otherwise global namespace of mixins. > > If the changeset for this is relatively straightforward, then I think this > will be a candidate for a 2.2 patch release, otherwise it'll need to wait > for 2.4. > > chris > > On Mon, Dec 14, 2009 at 3:08 PM, Chris Eppstein <[email protected]>wrote: > >> Thanks, I understand your use case. It looks like Nathan and I need to >> chat a little. >> >> Chris >> >> >> On Mon, Dec 14, 2009 at 2:35 PM, Tim Underwood <[email protected]>wrote: >> >>> Each site has a styles.sass that contains any customizations and then >>> includes the shared styles (usually just a whitelabel.sass that is >>> similar to the example below). I have about 2 dozen Sass variables >>> that can be overridden to control various colors (link colors, >>> backgrounds, borders, etc...) and about a dozen Sass mixins that can >>> be re-defined to control link behavior (color, text-decoration, hover, >>> etc...). The variables and mixins are the bulk of the customizations >>> but a few of the sites have additional styles that aren't configurable >>> via variables or mixins. >>> >>> -Tim >>> >>> On Dec 14, 2:05 pm, Chris Eppstein <[email protected]> wrote: >>> > Tim, >>> > >>> > That's quite a setup. Is there any per-site styling or are you >>> basically >>> > just generating two sets of CSS, one for white-labels and one for your >>> own >>> > site? >>> > >>> > chris >>> > >>> > On Mon, Dec 14, 2009 at 1:43 PM, Tim Underwood <[email protected] >>> >wrote: >>> > >>> > >>> > >>> > > Fair enough. First off let me say that I love Sass. Without it my >>> > > whole setup wouldn't work and would just be a big mess. So a big >>> > > THANKS to the developers! >>> > >>> > > My use case is probably somewhat unique. I run FrugalMechanic.com >>> > > where we power ~100 whitelabel versions of our website for partners >>> > > (e.g. autoparts.allaboutprius.com, autoparts.mustangblog.com, >>> > > autoparts.carzi.com). The easiest way to build the whitelabels is >>> to >>> > > embed our content into their stock html/css. For this to work I make >>> > > extensive use of the nested @import's to avoid css selector conflicts >>> > > with their stock css by making sure all of my css selectors are more >>> > > specific than theirs. >>> > >>> > > I currently have 126 sass files with 265 @import statements (some >>> > > nested, some not). The sass files that are used for the @imports >>> > > (both nested and non-nested) are all used as partials and kept in a >>> > > separate directory to avoid confusion with the sass files that are >>> > > actually used to generate the final css used by the browser. >>> > >>> > > I *personally* think the nested @import approach is cleaner because >>> > > it's more concise and less error prone (for me at least). >>> > >>> > > As a very simplified example, for frugalmechanic I have something >>> like >>> > > this at the top level: >>> > >>> > > @import yui-resets.sass >>> > > @import base.sass >>> > > @import styles.sass >>> > >>> > > For the whitelabels (where I nest all the rules) it looks something >>> > > more like: >>> > >>> > > #frugalmechanic >>> > > @import yui-resets.sass >>> > > @import base.sass >>> > > @styles.sass >>> > >>> > > Going the mixin route would mean changing the first one >>> > > (frugalmechanic) to: >>> > >>> > > @import yui-resets.sass >>> > > @import base.sass >>> > > @import styles.sass >>> > >>> > > +base >>> > > +yui_resets >>> > > +styles >>> > >>> > > And a whitelabel would look like: >>> > >>> > > @import yui-resets.sass >>> > > @import base.sass >>> > > @import styles.sass >>> > >>> > > #frugalmechanic >>> > > +yui_resets >>> > > +base >>> > > +styles >>> > >>> > > So for frugalmechanic I've gone from 3 lines of code to 6 and the >>> > > whitelabels have gone from 4 to 7 for this simplified example. >>> > > Multiply that by my 265 @import statements and that adds quite a bit >>> > > of code that IMHO doesn't add any value. >>> > >>> > > However, I think the change I'm more concerned about is needing to >>> add >>> > > the mixin definition to the top of all my @import'ed sass files and >>> > > indenting the entires contents of the file by 2 spaces. The 2 space >>> > > indenting makes those files less readable and more error prone since >>> > > if I mess up the indent I'll have styles escaping my nested rules >>> > > (which can be hard to debug). >>> > >>> > > -Tim >>> > >>> > > On Dec 14, 11:13 am, Chris Eppstein <[email protected]> wrote: >>> > > > It was intentionally taken away because, as I understand it, it was >>> never >>> > > > intended to work. >>> > >>> > > > I respect that you think this is a cleaner implementation, but I >>> > > disagree. I >>> > > > think it's very confusing. Mixins are how you indicate that a >>> particular >>> > > > block of styles are going to be nested into other selectors. Why do >>> we >>> > > need >>> > > > two mechanisms for mixing? If I open up >>> index_page_nested_rules.sass >>> > > there's >>> > > > nothing about that file that tells me how it's going to be used >>> except, >>> > > > maybe, a comment if you thought to add one. If I see one or more >>> mixins >>> > > > defined there, I understand, I have to go looking for where they >>> are >>> > > used. >>> > >>> > > > Perhaps there is some use case I haven't considered, so I'll >>> welcome you >>> > > to >>> > > > state your case for why you think this approach is better than >>> @import + >>> > > > mixins. >>> > >>> > > > Chris >>> > >>> > > > On Mon, Dec 14, 2009 at 10:17 AM, Tim Underwood < >>> [email protected] >>> > > >wrote: >>> > >>> > > > > In Haml/Sass 2.0.9 I'm able to do something like this: >>> > >>> > > > > .index_page >>> > > > > @import index_page_nested_rules.sass >>> > >>> > > > > .results_page >>> > > > > @import results_page_nested_rules.sass >>> > >>> > > > > And then everything in index_page_nested_rules.sass was nested >>> within >>> > > > > my index_page class. But in Haml/Sass 2.2.15 I get this error: >>> > >>> > > > > "Sass::SyntaxError: Import directives may only be used at the >>> root of >>> > > > > a document." >>> > >>> > > > > Was support for this intentionally taken away? Is there another >>> way >>> > > > > to accomplish the same thing? Mixins kind of work but aren't as >>> clean >>> > > > > as the nested @import's. >>> > >>> > > > > Thanks, >>> > >>> > > > > -Tim >>> > >>> > > > > -- >>> > >>> > > > > You received this message because you are subscribed to the >>> Google >>> > > Groups >>> > > > > "Haml" group. >>> > > > > To post to this group, send email to [email protected]. >>> > > > > To unsubscribe from this group, send email to >>> > > > > [email protected]<haml%[email protected]> >>> <haml%[email protected]<haml%[email protected]> >>> >< >>> > > haml%[email protected]<haml%[email protected]> >>> <haml%[email protected]<haml%[email protected]> >>> > >>> > > >. >>> > > > > For more options, visit this group at >>> > > > >http://groups.google.com/group/haml?hl=en. >>> > >>> > > -- >>> > >>> > > You received this message because you are subscribed to the Google >>> Groups >>> > > "Haml" group. >>> > > To post to this group, send email to [email protected]. >>> > > To unsubscribe from this group, send email to >>> > > [email protected]<haml%[email protected]>< >>> haml%[email protected]<haml%[email protected]> >>> >. >>> > > For more options, visit this group at >>> > >http://groups.google.com/group/haml?hl=en. >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "Haml" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected] <haml%[email protected]>. >>> For more options, visit this group at >>> http://groups.google.com/group/haml?hl=en. >>> >>> >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <haml%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
