Hi All, Just wondering if this feature (the nested imports) is still on the roadmap. It doesn't looks like it has been re-introduced yet.
-Tim On Wed, Dec 16, 2009 at 3:32 PM, Chris Eppstein <[email protected]> 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 >>> > > �[email protected] >>> > >>> > > 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]> >>> > > >. >>> > > > > 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]. > 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.
