Agreed. On Wed, Dec 16, 2009 at 3:42 PM, Nathan Weizenbaum <[email protected]> wrote:
> I think nested imports would shadow variables and mixins at the level where > they were imported, rather than overwriting. > > > On Wed, Dec 16, 2009 at 3:02 PM, Chris Eppstein <[email protected]>wrote: > >> 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] <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.
