[compass-devs] Blueprint grid isn't answering to variable overrides

[Lorin Tackett]

Fresh install of the latest stable gems. Using Staticmatic 0.11 alpha 4.

--- input ---

@import compass

@import blueprint

// Blueprint grid reset

$blueprint_grid_columns: 12

$blueprint_grid_width: 40px

$blueprint_grid_margin: 20px

#wrapper

  +container

--- output ---

#wrapper {
  width: 950px;
  margin: 0 auto;
  overflow: hidden;
  display: inline-block;
}

---

The width of #wrapper should be less than 950px with this grid.

Now, aside from the fact that the variable names *should* be using hyphens instead of underscores now, it's not working. The width of #wrapper is not changing at all.

I did the exact same test using a compass-generated standalone project in SCSS to remove both StaticMatic and syntax as a possible factors. Same fate.

-LT

--
You received this message because you are subscribed to the Google Groups "Compass Development" group.
To post to this group, send email to compas...@googlegroups.com.
To unsubscribe from this group, send email to compass-devs...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/compass-devs?hl=en.

[Lorin Tackett]

Huh...

--- input ---

// Blueprint grid reset

$blueprint_grid_columns: 12

$blueprint_grid_width: 40px

$blueprint_grid_margin: 20px

@import compass

@import blueprint

---

It works if you set the variables before you import Blueprint. This is not how it has always worked. Is this way it is supposed to work from now on?

-LT

[Nathan Weizenbaum]

Could this be because of the use of @extend?

[Lorin Tackett]

For me, no. I'm not using @extend. I'm not sure about what Compass is up to behind the scenes.

[Chris Eppstein]

http://compass-style.org/docs/tutorials/configurable-variables/

That's how it was always meant to work, there might be some cases where changing it after will work, but setting it before is always considered the best approach.

chris

[Lorin Tackett]

I think this flies in the face of a well understood CSS principle: "if I override something with the same name further down the stylesheet, that takes precedence."

This is saying that you setup your overrides FIRST, then @import the mixins, and when you call the +mixin you want, the override you setup is used.

I'm not saying it's the wrong approach, and I personally see nothing wrong with it, as a Sass user. I just want more of an explanation from you as to why this is the way it needs to be done. 

It caught *me* off guard as a very competent Sass and Compass user. So much so that I thought it was a bug.

Putting myself in the CSS adopter's shoes, I'd find this concept to be slightly backwards and "programmery".

-LT

[Chris Eppstein]

Ok so here's the thing. As a rule, putting it before will _always_ work. So that's the best practice. This is because an imported stylesheet might decide to generate some base css for your page (this is going to happen more with @extend now) and some of those styles might depend on the variables being correctly set from the start.

But assigning late will still work in a lot of cases:

$foo : 1px;

@mixin asdf($f : $foo) { div { border-width: $f; } }

$foo : 5px;

@include asdf;

Produces:

div { border-width: 5px; }

I don't know why your particular case didn't work, but we can certainly figure it out. But I'm not going to produce documentation that tries to tell them when and where they can do early vs. late assignment -- advanced users will figure it out.

Anyways, please let me know how you think the docs should change, or better yet, submit a patch :)

chris

[Brandon Mathis]

I ran into this earlier, and thought how nice it would be if I could scope defaults to a single declaration. Obviously this is caused by the way conditional assignment occurs, when you import the mixin, there is no value assigned for the global default, so it assigns the default, when you call the mixin, that default is no longer conditional.

As a result I end up having to create a _defaults.sass where I set global values for the mixin defaults. This is currently the only way to do it without passing the variables through a mixin. I'd love to be able to write mixins that use locally scoped variables to override defaults. It would be especially handy for complex mixins like the one for image sprites where I end up having to set defaults in multiple places.

That said, it could adversely affect the simplicity that we have now. Chris is this madness?

- Brandon

[Chris Eppstein]

Variable scoping will be addressed to some extent via nested @import in a future release. Some basic concept of namespaces may be needed at some point too.

Nathan and I have discussed this in depth a couple of times, but we usually end up at "not yet -- let's wait until we have more users complaining so we understand the problem space better". Even now, it feels somewhat premature to discuss the specifics, but I'll never stop brainstorming when folks are in the spirit for it.

Chris

[Lorin Tackett]

Compass-generated projects have the partials/_base.scss file, so we can certainly point people there when this issue crops up on those, but in roll-your-own cases, I think people might notice this more.

My problem was just a poor understanding of the difference between plain ol' assignment and guarded assignment. To tell you the truth, I don't override Compass' variables that often.

I certainly don't want the documentation to suffer from TL;DR, but I think I can flesh out wordier explanations for some of the trickier parts like this.

-Lorin

[Nathan Weizenbaum]

I'm curious what's causing this particular case of overriding.

Might it be worth considering a change in variable semantics to account for this case? We could conceivably handle all variable declarations before handling any of the properties in which they're used. This could pose a serious problem if we ever wanted to allow attribute accessors, but with the current feature set it would be reasonably unproblematic.

Speaking of changes in variable semantics, I've heard other users complaining about nested variables not being locally scoped. This is also a change that's worth considering. I'm not sure nested imports would really be able to help that much.