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. Article post type

    Using Web Platform Tests to Write and Test Polyfills

    Learn how to leverage Web Platform Tests to ensure your polyfills are implementing upcoming browser features correctly, including how to generate a comprehensive report of failing/passing tests on each change.

    see all Article posts
  2. Article post type

    Python Web Conference 2023 Recap

    OddBird sponsored Python Web Conference 2023 and sent me to attend. In this article I showcase my favorite talks and activities from this excellent online event, including a list of useful resources for web application security, introductions to new PaaS providers, and a comparison of the most popular Python web frameworks.

    see all Article posts
  3. see all Article posts