Hey guys,
Thanks for the thoughtful replies.
Re lexical vs dynamic scoping: for some reason I mistakenly thought
mixins just acted like a sort of substitution macro (no scoping at
all). So I was only thinking about scoping in the selector hierarchy,
and asking about syntax to define a local var without modifying the
global one (shadowing, as Nathan said). Chris, your code example shows
exactly what I was asking about.
But Nathan's right: since mixins don't have access to their calling
scope, I can't do what I was hoping to do, even with a way to create
local variables that shadow global ones.
For what it's worth, here's what I'm trying to do in a nutshell. In
our Compass plugin as it currently stands[1], you do something like
this:
!grid_unit = "em"
!total_cols = 10
!col_width = 7
!gutter_width = 1
#page
+container
#nav
+columns(2)
#content
+columns(8)
#one
+columns(5, 8)
#two
+columns(3, 8)
And it generates a fluid-elastic grid, with the page-width set in ems
and given a max-width:100% (so it shrinks with the browser window),
and all the internal widths set in percentages that the plugin
automatically calculates for you. But +columns mixin on nested
elements needs the optional second argument so you can tell it that
#one and #two are inside an 8-column-wide context, so it will generate
the correct percentage width. That extra argument is easy to forget,
and seems like it shouldn't really be needed; I was hoping that with
scoped variables I could remove it (along with similar arguments to
some other mixins).
Chris, you're totally right that the selector hierarchy is not the
DOM, and we're certainly aware that if you wanted to, you could easily
break this; e.g. with other intervening DOM elements with widths set
some other way. We're definitely doing some "magical" things to reduce
boilerplate as much as possible (for instance, setting global
variables like !total_cols and !col_width as class-vars on
Sass::Script::Functions so other width-calculating functions can
access them without having to keep passing them in everywhere). I hear
the argument that "magic" might make it less clear to the user how it
all works, but in practice I'm not sure the tradeoff isn't worth it.
It's not hard to use this consistently in a way that doesn't break:
just keep your grid layout work in a single Sass selector hierarchy,
which is the natural way to do it anyway.
Feedback definitely welcome.
Carl
[1] http://github.com/ericam/compass-susy-plugin/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
