Susy: Omega and Responsive Grids - css

Question

When using Susy, you put an "omega" flag on the last item of a row to remove its margin-right. For example, let's say we have a bunch of items we need to lay out on a 12-column grid:
<div class="item">...</div>
<div class="item">...</div>
<div class="item">I'm the last of the row</div>
<div class="item">...</div>
And the SCSS:
.item{
#include span-columns(4);
#include nth-omega(3n);
}
But our grid is responsive, and smaller displays use an 8-column grid. The problem is that omega now needs to appear on 2n, and not 3n:
<div class="item">...</div>
<div class="item">I'm the last of the row</div>
<div class="item">...</div>
<div class="item">...</div>
So my question is: with Susy, do you need to redefine your columns for each breakpoint, or is there some way to define column widths once and for all and let the omega naturally fall at the right place?
And if not, does any other grid system offer that?

Answer 1

Solving your issue with Susy
Susy allows overriding the number of columns. Many Susy mixins allow that — every mixin that accepts the $context argument.
But the best way to override a context is with the at-breakpoint mixin:
// Defining the breakpoints
$mobile-to-medium: 400px;
$medium-to-large: 800px;
// Defining columns
$columns-small: 1;
$columns-medium: 8;
$columns-large: 12;
// Starting with a one-column mobile grid
$total-columns: $columns-small;
// Global styles go here
// Mobile-only styles
#include at-breakpoint($total-columns $mobile-to-medium) {
// ...
}
// Medium-only styles go here
#include at-breakpoint($mobile-to-medium $columns-medium $medium-to-large) {
.item{
#include span-columns(3);
#include nth-omega(2n); } }
// Large-only styles go here
#include at-breakpoint($medium-to-large $columns-large) {
.item{
#include span-columns(4);
#include nth-omega(3n); } }
Omega supposes layered responsiveness: mobile styles are applied to all widths; medium styles are applied to medium and large widths, large styles are applied to large widths.
The approach above is not layered: mobile styles are applied only to mobile width, etc. This way you don't need to worry about omega applied where it's not supposed to go.
To use the Omega layered approach, just remove the third element (max-width) in at-breakpoint calls. But then you have to apply #include remove-nth-omega():
// Defining the breakpoints
$mobile-to-medium: 400px;
$medium-to-large: 800px;
// Defining columns
$columns-small: 1;
$columns-medium: 8;
$columns-large: 12;
// Starting with a one-column mobile grid
$total-columns: $columns-small;
// Global styles go here
// Medium and large styles go here
#include at-breakpoint($mobile-to-medium $columns-medium) {
.item{
#include span-columns(3);
#include nth-omega(2n); } }
// Large-only styles go here
#include at-breakpoint($medium-to-large $columns-large) {
.item{
#include span-columns(4);
#include remove-nth-omega(2n);
#include nth-omega(3n); } }
An overview of an omega-less approach
There are SASS grid systems that don't use the "omega" parameter (not to be confused with the Omega theme for Drupal) that's necessary to be applied for the last item in each row. Instead, you provide each element's position (which column the item starts at) in addition to its column width.
To make that possible, another CSS positioning approach is used, known as "isolation". The first framework to use this approach was Zen Grids.
Susy also has support for this method with its isolate and isolate-grid mixins.
This overview would not be complete without mentioning Singularity, the latest and most advanced SASS grid framework. It supports both postioning methods and is extendable to support more in the future (like flexbox which has recently been added to Compass).

Answer 2

In your case, you will have to redefine the total number of columns (context) in the new breakpoint. As for nth-omega, you can use #include remove-nth-omega(3n) to negate the first call before explicitly calling the second, but I consider that a CSS code smell (having to neutralize properties) so I recommend using media-query splitting to avoid that.
Also, I'm not aware of any framework that can automatically do that for you.