// ---- | |
// Sass (v3.3.0.rc.1) | |
// Compass (v0.13.alpha.10) | |
// ---- | |
$grid: ( | |
small: 90% 8 1/4, | |
medium: 80% 8 1/4, | |
large: 80% 12 1/4, | |
); | |
$content-grid: ( | |
left: 100% (4 8) 1/4, | |
right: 100% (8 4) 1/4 | |
); | |
@function _grid($map, $g, $attr: false) { | |
$list: map-get($map, $g); | |
@if $attr == container-width { @return nth($list, 1) } | |
@if $attr == columns { @return nth($list, 2) } | |
@if $attr == gutters { @return nth($list, 3) } | |
@if $attr == total-columns { | |
$columns: nth($list, 2); | |
@if type-of($columns) != list { @return $columns } | |
$sum: 0; | |
@each $n in $columns { | |
$sum: $sum + $n; | |
} | |
@return $sum; | |
} | |
@return $list; | |
} | |
@function grid($g, $attr: false) { | |
@return _grid($grid, $g, $attr); | |
} | |
@function content-grid($g, $attr: false) { | |
@return _grid($content-grid, $g, $attr); | |
} | |
output { | |
a: length(map-get($grid, small)); | |
b: grid(small); | |
c: grid(small, container-width); | |
d: content-grid(left, gutters); | |
e: grid(medium, columns); | |
f: grid(medium, total-columns); | |
g: content-grid(left, total-columns); | |
} |
output { | |
a: 3; | |
b: 90% 8 1/4; | |
c: 90%; | |
d: 1/4; | |
e: 8; | |
f: 8; | |
g: 12; | |
} |
To clarify: set-grid()
and susy-set()
accept both maps and shorthand syntax.
I just added the option to mix maps and keyword shorthand lists. It only required a few lines of code. :)
Wow, that's really cool!
I like the idea of putting grids into a map rather than using a variable for each grid because it provides something like a namespace. I've been doing this to organize other types of data, too, like colors and font-sizes. (When I say "I've been doing this," I mean in the few days since I started playing with Sass 3.3, haha.) Plus, with maps, you can do things like iteration that aren't possible with normal variables, even if they are semantically named.
I'm not not sure if this is something that should be part of Susy or if it's best left up to each person's individual preferences, but here's how it might work:
$_grids: ();
@mixin add-grid($g, $name) {
$_grids: map-merge($_grids, ($name: $g));
}
@function grid($name) {
@return map-get($_grids, $name);
}
$grid-1: 90% 8 1/4;
$grid-2: 100% (4 8) 1/4;
@include add-grid($grid-1, 1); // Add grid-1
a { output: grid(1) }
b { output: grid(2) } // Will output nothing since it hasn't been added yet
@include add-grid($grid-2, 2); // Add grid-2
c { output: grid(2) } // Now it is output
Essentially, this is just abstracting calls to map-get()
and map-merge()
to make the syntax more friendly.
I went ahead and created another Gist for the above: https://gist.github.com/acdlite/7308879
So if Susy used this pattern, my example grid()
function above would correspond to susy-get()
.
Question: does susy-get()
return the total number of columns in a grid? Not sure the best way to phrase this, but for instance, a grid with columns: (4 8)
has a total of 12 columns. I think that would be a useful feature.
This is great. I'm already working on converting Susy 2 for maps. Here's a few functions that I've been using:
set-grid()
along with the shorthand.set-grid()
(and the alternativesusy-set()
) both accept and return maps.parse-grid
accepts either map or shorthand, and returns a map.susy-get($setting, $grid)
will get any setting from any grid (map or shorthand).parse-span
(and thereforspan
mixin and function) accept maps or shorthand. The parser returns maps.span-get($setting, $span)
will get any setting from any span map or shorthand).I just realized I can also easily accept maps as part of the shorthand, in case you wanted to do this:
With all that in place, is there anything that we're still missing? Scanning it quickly, the only difference I see off-hand is the syntax: your proposal has a map of grids, where the current approach would use a variable for each grid. Am I missing anything else? Thoughts?