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]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
