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

    Generating Frontend API Clients from OpenAPI

    API changes can be a headache in the frontend, but some initial setup can help you develop and adapt to API changes as they come. In this article, we look at one method of using OpenAPI to generate a typesafe and up-to-date frontend API client.

    see all Article posts
  2. Stacks of a variety of cardboard and food boxes, some leaning precariously.
    Article post type

    Setting up Sass pkg: URLs

    A quick guide to using the new Node.js package importer

    Enabling pkg: URLs is quick and straightforward, and simplifies using packages from the node_modules folder.

    see all Article posts
  3. Article post type

    Testing FastAPI Applications

    We explore the useful testing capabilities provided by FastAPI and pytest, and how to leverage them to produce a complete and reliable test suite for your application.

    see all Article posts