hmm. That's intriguing. I hadn't put together that perhaps & could work together with that feature....
On Fri, Jul 17, 2009 at 8:50 PM, Nathan Weizenbaum <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
