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]>.
> > 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.


Reply via email to