Sass nested @import's no longer work?

[Tim Underwood]

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

[Lorin Tackett]

Feasibly, you could use mixins to accomplish what you're doing in Haml 2.2

@import nested_rules.sass
.index_page
+index_page_nested_rules
.results_page
+results_page_nested_rules

and inside nested_rules.sass you could declare your mixins:

= index_page_nested_rules
some: sass-rules
= results_page_nested_rules
some-more: sass-rules

> --
>
> You received this message because you are subscribed to the Google Groups "Haml" group.
> To post to this group, send email to ha...@googlegroups.com.
> To unsubscribe from this group, send email to haml+uns...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/haml?hl=en.
>
>

[Chris Eppstein]

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

[Lorin Tackett]

Oh oops.. thanks Chris. I misunderstood what Tim was after. Totally missed the bit about mixins at the bottom.

-Lorin

[Jacques Crocker]

I personally think it would be a pretty awesome feature to be able to reuse any stylesheet as a mixin by importing it indented. That way it automatically scopes everything. 

Seems clean and understandable to me. Mixins work great, but not for everything. When you already have some styles somewhere and you need to reuse it scoped on another page, cleanest way would be to just import the file nested within another style rule.

On Dec 14, 2009, at 11:13 AM, Chris Eppstein wrote:

[Chris Eppstein]

On Mon, Dec 14, 2009 at 12:12 PM, Jacques Crocker <merb...@gmail.com> wrote:

Mixins work great, but not for everything. When you already have some styles somewhere and you need to reuse it scoped on another page, cleanest way would be to just import the file nested within another style rule.

No, that would be the fastest way. The cleanest way, in my opinion is to refactor given your new usage requirements.

chris

[Nathan Weizenbaum]

There are a few things I don't like about import-anywhere, in addition to Chris's comments. First, I don't like that it suddenly matters which styles are in which file. Everywhere else in Sass (and CSS), as long as you import files together, which styles are in which file is irrelevant.

Also, allowing imports not at top-level means that you can have invalid Sass files that still work when being imported (e.g. ones that only contain properties).

That said, the latter issue could potentially be checked for, and if you think about files as separate stylesheets it's nice to be able to use those in a scoped way. I'm potentially open to being convinced.

--

[Tim Underwood]

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 <ch...@eppsteins.net> 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 <timunderw...@gmail.com>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 ha...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > haml+uns...@googlegroups.com <haml%2Bunsu...@googlegroups.com>.

[Chris Eppstein]

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

To unsubscribe from this group, send email to haml+uns...@googlegroups.com.

[Tim Underwood]

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 <ch...@eppsteins.net> 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
>

> > haml%2Bunsu...@googlegroups.com<haml%252Buns...@googlegroups.com>

[Chris Eppstein]

Thanks, I understand your use case. It looks like Nathan and I need to chat a little.

Chris

To unsubscribe from this group, send email to haml+uns...@googlegroups.com.

[Chris Eppstein]

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

[Jacques Crocker]

Awesome. Will part of this change allow us to define nested mixins as well?

[Chris Eppstein]

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

[Nathan Weizenbaum]

I think nested imports would shadow variables and mixins at the level where they were imported, rather than overwriting.

[Chris Eppstein]

Agreed.

[Tim Underwood]

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

[Chris Eppstein]

I consider it a "nice to have" for the 3.0 release. But it is definitely on the roadmap.

chris