One thing we may do in the future is provide a way to get the value of properties defined for a certain selector. With this, you might be able to get access to the properties of parent selectors from within a mixin. But that's somewhat off in the distance.
On Fri, Jul 17, 2009 at 8:23 PM, Carl Meyer <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
