Skip to main

Susy Next, Alpha 5

Susy Next alpha 5 is out, and loaded with changes. We now require Sass 3.3, we no longer require Compass, and there have been major syntax improvements. We’re getting real close to launch, and we’d love to know what you think. Play around, and let us know!

Susy Next is almost feature complete! Alpha 5 is loaded with changes – some as a result of alpha testing, but mostly in response to the new power of Sass 3.3. This is likely to be our final alpha. With a bit more user testing and some minor cleanup, we hope to hit beta soon and then land a stable version along side the upcoming releases of Compass and Sass.

Sass 3.3 is awesome, and we’ve made a lot of changes in Susy to take full advantage of the new toys. We started integrating the new SassScript Maps data type (not to be confused with Source Maps), and the side benefits were huge. We’re also using the new variable-exists() and mixin-exists() functions to check for the presence of various compass features, and degrade gracefully if they aren’t available.

In brief: Sass 3.3 is now required and Compass is no longer required, although we do tie in with Compass features such as vertical-rhythms if they are available.

The first thing to do, after upgrading Sass, is to translate your Susy settings into a single map of key/value pairs. For a long time the only way to establish defaults and user overrides in a Sass plugin has been to use variables. In Susy 1 and the early alpha releases, we did the same:

$columns: 6;
$gutters: 1/4;
$gutter-position: inside;

But that clogs up the global namespace in ugly ways. Now, thanks to SassScript Maps, we have a new solution that keeps everything contained, and comes with side-benefits for anyone using multiple grids:

$susy: (
  columns: 6,
  gutters: 1/4,
  gutter-position: inside,

There is only one variable, named $susy, that takes a map of all your settings. You can still use the grid shorthand with set-grid or use-grid:

@include set-grid(6 1/4 inside);

But you can also mix-and-match shorthand with maps, both for grid-settings and for spans:

$large: (
  columns: 12,
  container: 90em,

@include use-grid($large inside) {
  // ...

@include span(3 $large);

If you need access the current value of a setting, just use susy-get(setting-name):

$current-columns: susy-get(columns);

Susy Next supports several gutter styles: after (the Susy 1 approach), before, inside, inside-static, and split. Before, after, and split all use margins. Inside and inside-static use padding.

In previous alphas, split worked like before and after, and you had to remove the first and last edge-gutters. That felt wrong, so we fixed it. Split gutters now work similar to inside gutters, and there is no reason to remove them at the edges of the grid. That simplifies most things, but it complicates nesting. You don’t want gutters added to the edges of an outer element, and then added again to the edges of inner elements.

Susy is very flexible, and there are many ways you can work around that problem already, but we added a container shortcut to make it easier.

.outer-element {
  @include span(6 of 12 container);
  .inner-element { @include span(3 of 6); }

People are often confused about spanning full widths in Susy. I often see @include span(12 of 12); or the Susy 1 equivalent. That’s not necessary, and adds a fair amount of extra output that you don’t need. Really, in most cases you don’t need anything at all – block elements span the full width by default. Sometimes, though, you need to clear the previous floats (clear: both), or you need to clear internal floats (clearfix), but those seemed simple enough that we didn’t bake them in.

That’s changing. Thanks to the added complexity of inside and split gutters, which also need to be applied on full-width elements, we’ve added a full mixin. Use it!

// Wrong! (usually)
@include span(12 of 12);

// Right!
@include full(of 12);

We’re in the final stages here, working hard to get the last pieces in place and give it a coat of polish before it lands. Any help or feedback is appreciated, just file an issue on GitHub, and we’ll talk.

Recent Articles

  1. A stand of smartphones
    Article post type

    When to Choose a Native Mobile App

    Part 2 – Responsive Web App vs Native Mobile App vs Progressive Web App

    If you have an idea for a digital product, you may be wondering if you should build a responsive web app, a native mobile app, or a progressive web app. Is one option inherently better? What are the pros and cons? This is part 2 of a three-part series unpacking…

    see all Article posts
  2. spider web with dew drops
    Article post type

    When to Choose a Responsive Web App

    Part 1 – Responsive Web App vs Native Mobile App vs Progressive Web App

    The decision of what platform to use to build your app is quite important – affecting project scope, timeline, and budget. But understanding the differences between a responsive web app, a native mobile app, and a progressive web app – and deciding which one is right for your project …

    see all Article posts
  3. The top front of a bright yellow shipping container with the door open and a blue sky behind it
    Article post type

    Can We Query the Root Container?

    The complexities of containment, overflow, and ‘propagation’

    I spoke about Container Queries at both Smashing Conference (San Francisco) and CSS Day (Amsterdam) – where I recommended setting up a root container to replace most media queries. Since then, Temani Afif pointed out a few issues with that approach, and sent me down a rabbit hole of overlapping…

    see all Article posts