Menu Search
Jump to the content X X
Smashing Conf New York

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf New York, dedicated to smart front-end techniques and design patterns.

Smarter Grids With Sass And Susy

If you’re a designer, you’ll know that grids are your friends. More often than not, they’re the vital architecture that holds a beautiful design together; they create rhythm, structure your page, lead the eye, and prevent the whole thing collapsing in a sloppy mess.

I’m a firm advocate for designing with the browser: prototyping with HTML and CSS has many clear advantages over static Photoshop comps, which have less value for the responsive web. Unfortunately, HTML, CSS and grids aren’t natural bedfellows: the progression of web standards over the years has been lacking in this area, meaning we have to grapple with floats (which were never designed to be used this way) and clearfixes — not ideal when you want to spend less time debugging layout and more time crafting experiences.

Further Reading on SmashingMag: Link

The relatively new implementation of the flexbox and CSS grid layout modules are on course to free us from the constraints of floats and allow us to create some pretty interesting layouts — which I’m excited about — but they’re not a magic bullet. Even with those, coding up a layout can still be a lengthy process for a designer, and require you to remember a bunch of not very intuitive properties.

Happily, lots of tools currently exist to enable you to quickly design grids for the web, from CSS frameworks like Bootstrap5 and Foundation6, to sites like Responsive Grid System7. However, frameworks have their drawbacks, such as requiring you to add a large number of classes to your markup, and delivering a bloated codebase that can be bad for performance.

Luckily for us, solutions exist to the problem of creating fast, responsive, fully customizable grids: Susy8 is a Sass-based grid framework. It’s very lightweight and enables you to create entirely custom grids in CSS without touching your markup.

Susy was developed by Eric M. Suzanne, with support from Chris Eppstein — creator of Compass and co-creator of Sass — so it’s very well supported in the Sass community and it’s rapidly gaining in popularity.

Framework Or Not? Link

I tend to refer to Susy as a framework, but it may be more accurate to call it a grid system. Unlike more traditional frameworks, Susy doesn’t require you to add classes to your HTML elements. Susy is written entirely in your SCSS file by adding mixins and functions, using media queries to customize your layout at your own specified breakpoints. It enables you to keep content and style entirely separate — not essential all the time, but widely viewed as best practice.

Before we continue, I should point out that Susy isn’t the only solution: Zen Grids9 by John Albin and Jeet10 by Cory Simmons are two others. Singularity11 is also a pretty interesting framework, which works in a similar way to Susy, using Sass mixins rather than adding classes to your HTML. However, Susy has a growing community and helpful documentation, making it a good choice to get started with.

Advantages Link

Why might you want to use Susy in your next project? There are several advantages:

  1. (Relatively) Easy to Learn
    If you’ve used other frameworks (like Bootstrap or Foundation), and if you’re familiar with Sass at all, Susy shouldn’t be too difficult for you to pick up. Even if you’re fairly new to Sass, Susy doesn’t require in-depth knowledge and is a great way to start! The examples in this article assume a working knowledge of Sass, so it’s worth reading up a little if you’re not familiar.
  2. Speed Up Your Workflow
    Unlike many other frameworks, Susy doesn’t come with a bunch of default styling that you need to overwrite. In fact, Susy has no styling: it’s purely a grid layout system. Its purpose is to do the maths for you — anything else is for you to add. Once you’re familiar with a few of Susy’s mixins, you’ll find it’ll save you time and free you up to concentrate on design.
  3. Use as Much or as Little as You Like
    As with Sass, you can pick and choose what works for you. We’ll focus on a few fairly simple examples here, but you can use Susy to do some pretty complex things if you’re so inclined!

I should also point out that while Susy currently relies on traditional floats to position your grid, the documentation indicates that flexbox and CSS grid layout could well be forthcoming, which will make it even more powerful!

Getting Started Link

Susy was designed to work with Compass12, so if you already have Compass installed then setting up Susy is straightforward. You don’t actually need to use Compass in order to use Susy — Susy is compatible with just about any Sass workflow — but for the purpose of getting started I’ll be using Compass as a primary example.

To install Susy, simply run the following in the command line:

$ gem install susy

(If you get an error, you may need to prefix this command with sudo.)

Then set up your new project. If you’re using Compass, in your config.rb you need to add require 'susy'. Then, in your main SCSS file (in this case screen.scss) add @import "susy"; to import Susy into your project.

Alternatively, CodeKit13 is an excellent app for getting up and running with everything you need and allows you to add Susy to your project quickly and easily.

Finally, we need to create an index.html file in our project folder to house our markup, and link it to our style sheet.

Building Our First Susy Grid Link

Assuming you’ve gone through the necessary steps to run Susy in your project, we’re ready to create our first layout. First of all, we need to define some parameters for our grid in a map at the beginning of our main SCSS file. If you’ve come across Sass maps, you’ll be familiar with the syntax:

$susy: (
  columns: 12,
  container: 1200px,
  gutters: 1/4,
  global-box-sizing: border-box,
  debug: (image: show)

In this map you can define pretty much any of the global settings for your grid, from the number of columns to gutter width, all of which are listed in the Susy documentation14. If you don’t enter a setting in your map, Susy will simply use its default settings. There are a few things we’ll need to define to create our grid:

  • The number of columns we’ll use.
  • The maximum width of the container. If you don’t specify a width, your container will be 100% of the width of the viewport, like any block element. You might want this in some cases but, especially while we’re learning, setting a maximum width allows us to see more clearly what’s going on.
  • Gutters. By default Susy includes gutters as right-hand margins on your columns and at one quarter (1/4) of the column width. You can change the gutter ratio here, or use gutter-position15 to decide how you want gutters to behave.
  • Box-sizing. I always prefer to set this to border-box. (Susy’s default is content-box.)
  • The debug image. Setting this to show displays a background image showing your column grids, useful for making sure everything is aligned correctly and your elements behave as they should.

Creating A Basic Layout Link

We’re going to start by creating this simple layout using Susy:

A basic webpage layout16
A basic webpage layout. (View large version17)

See the Pen Susy Grid Example 1A18 by Michelle Barker (@michellebarker372819) on CodePen382920.

A basic grid layout created using Susy (on CodePen)

We’ll start with some markup containing a header, a main content area with article and sidebar, and a footer.

<main class="wrapper">

As I previously mentioned, Susy depends entirely on CSS and Sass to customize your grid, so you don’t need to add anything else to your HTML. The most important feature for creating grids in Susy is the span mixin. Use @include to include the mixin in your Sass. As you can see from the image, we want our header and footer to take up 100% of the container width, so we don’t need to do anything here. But we need our <article> and <aside> elements to take up eight columns and four columns respectively in our twelve-column grid. In order to achieve this we need to use the span mixin:

/* SCSS */

article {
  @include span(8 of 12);
  /* More styles here */

aside {
  @include span(4 of 12 last);
  /* More styles here */

There are a couple of things to note here:

  1. Susy depends on context: we could easily write @include span(8) for the <article> element, which would produce the same result because we already defined our layout as four columns in the map. However, if we wanted to override the map for this particular element (say, subdivide this area of our layout into a greater number of columns), we need to specify the context — in this case, twelve columns.
  2. We want the <aside> to be the last item in the row, so we’ve added the word last to the mixin. This tells Susy to remove the right-hand margin on that element so that it fits on the row.

If we take a look at our CSS file, we’ll see the above Sass compiles to:

article {
  width: 66.10169%;
  float: left;
  margin-right: 1.69492%;

aside {
  width: 32.20339%;
  float: right;
  margin-right: 0;

You can see that Susy has calculated our column widths and gutters based on the settings we specified in our map.

In the Codepen example I’ve included some dummy content, as well as a little padding and a background color on our elements. Without these our grid would simply be invisible, as Susy has no default styling.

As we’re floating elements, we also need to remember to clear our footer:

header {
  padding: 2em;
  background-color: #FF4CA5; /* Of course, you can define your colours as variables if you prefer! */

article {
  @include span(8);
  padding: 2em;
  background-color: #ff007f;

aside {
  @include span(4 last);
  padding: 2em;
  background-color: #CC0066;

footer {
  clear: both;
  padding: 2em;
  background-color: #7F2653;

Finally, we’ll include the container mixin in our main element to give our content a maximum width and position it in the center of the page by setting the left and right margins to auto:

main.wrapper {
  @include container;

With these additions, we get this result:

A basic webpage layout with dummy content21
A basic webpage layout with dummy content. (View large version22)

Refining Our Grid Link

We could do with separating the elements to make our layout more pleasing. Let’s add a bottom margin to our <header>, <article> and <aside> elements. What would make an even more appealing layout would be to make our bottom margins the same width as our column gutters. With Susy, we can do this using the gutter function (as opposed to the mixin):

header, article, aside {
  margin-bottom: gutter();

As we haven’t specified a value in the gutter function, Susy will use our map settings; that is, 1/4 column-width in a twelve-column layout. But if, for instance, the section we were working on was only eight columns wide, we may want to specify gutter(8) to create the same effect.

Our SCSS file now looks like this:

main {
  @include container;

header, article, aside {
  margin-bottom: gutter();

header {
  padding: 2em;
  background-color: #FF4CA5;

article {
  @include span(8);
  padding: 2em;
  background-color: #ff007f;

aside {
  @include span(4 last);
  padding: 2em;
  background-color: #CC0066;

footer {
  clear: both;
  padding: 2em;
  background-color: #7F2653;

Now our layout looks like this:

A webpage layout refined with gutters23
A webpage layout refined with gutters. (View large version24)

Mixins Vs. Functions Link

We just used gutter as a function, as opposed to including it in a mixin. It’s worth noting that span, gutter and container can all be used as both mixins and functions. The Susy documentation outlines use cases for each, but our next example should help give you an understanding of the circumstances in which a function might be useful.

There’s one more thing that will no doubt be extremely handy to you as a designer: the gallery mixin. As the Susy documentation succinctly puts it, “Gallery is a shortcut for creating gallery-style layouts, where a large number of elements are layed [sic] out on a consistent grid.” It’s great for unordered lists, for example, if you want to create a portfolio page.

A gallery page layout25
A gallery page layout. (View large version26)

Below is the CodePen for this gallery layout.

See the Pen Susy Grid gallery example27 by Michelle Barker (@michellebarker372819) on CodePen382920.

A gallery layout grid created using Susy (on CodePen)

We’ll use the following markup for a gallery of twelve items — again, I’ve added some placeholder content in the Codepen example:

    <ul class="gallery">

We’ll keep the same SCSS from the previous example, with the addition of the following: {
  padding: span(1 of 8);
  list-style: none;
.gallery li {
  @include gallery(2 of 6);
  margin-bottom: gutter(6);
  &:nth-last-child(-n + 3) {
    margin-bottom: 0;

There are a few things going on here:

  1. First, we’re using span as a function to add one column-width of padding all the way around our gallery. As the element is eight columns wide, taking up one column-width on either side leaves us with the remaining six columns for our gallery items.
  2. Using the gallery mixin on our <li> element (@include gallery(2 of 6)), we’re telling Susy that each item should take up two columns in our six-column width. That means that each row will hold three gallery items.
  3. Using the gutter function (margin-bottom: gutter(6)) we’re adding a bottom margin the equivalent of one gutter-width in our six-column context to each item in our gallery. I’m using the :nth-child pseudo-class to remove the bottom margin from our last row, giving us a perfectly even amount of spacing around our gallery.
  4. As we’re floating elements, we’ll also need a clearfix on the parent element (in this case the ul element). In the example, I’m using Compass’s clearfix, but you could create your own mixin, or write it longhand. {
      @include clearfix;


A gallery page layout populated with content30
A gallery page layout populated with content. (View large version31)

Susy For Responsive Web Design Link

Although the examples we’ve walked through so far are based on fluid grids (Susy’s default), they aren’t responsive — yet. At the beginning of this article I mentioned that Susy is a great tool for designing responsively. Let’s look at one more example to see how we can use Susy to create a layout that adapts to different viewport sizes.

In this demo we’ll use use media queries in our Sass, along with Susy’s layout mixin to customize our grid for different breakpoints.

You’ll recall that at the beginning of our SCSS file we created a map with our global settings. In fact, we can create any number of maps and summon them at will into our layout with this mixin. This is useful if at a certain breakpoint you want to switch from, for instance, a twelve-column to a 16-column layout with no gutters. Our second map may look something like this:

$map-large: (
  columns: 16,
  container: auto,
  gutters: 0,
  global-box-sizing: border-box

For this example I’ve created a simple gallery webpage displaying a collection of photos of found typography. Taking a mobile-first approach, our first step is to create a single-column view, where our main elements take up the full width of the page. However, in our gallery section, we want our images to display in rows of two once our viewport gets wider than, say, 400px and in rows of three after 700px. We’re using a twelve-column grid in our global settings, so all we need to do is instruct Susy to set our gallery items at six columns out of twelve, and four columns out of twelve respectively, in min-width media queries:

li {
  @media (min-width: 480px) {
    @include gallery(6);
    margin-bottom: gutter();
  @media (min-width: 700px) {
    @include gallery(4);
    margin-bottom: gutter();

At widths above 700px, this is what our webpage looks like:

Responsive gallery layout at 700px wide32
Responsive gallery layout at 700px wide. (View large version33)

At desktop sizes we’re going to make our layout a little more complex. Here we want our header to display as a bar on the left-hand side and our gallery items to display in rows of four on the right of the screen, with no gutters. To achieve this we’re going to switch to a 16-column layout, as defined in the new map we created a moment ago.

We’re going to use the layout mixin as follows:

@media (min-width: 1100px) {
  @include layout($map-large);
  header {
    @include span(4);
  main {
    @include span(12 last);
  li {
    @include gallery(3 of 12);
    margin-bottom: 0;

The layout mixin sets a new layout for our grid. Any code following this mixin will be affected by the 16-column layout we specified. (Note: if you want to revert back to a different layout, you’ll need to use this mixin again to call a different map, as your code will be affected by this mixin until you specify otherwise!)

In this instance, the <header> element will span 4 colomns out of 16 and the main content area will span the remaining 12 out of 16 columns. Because our gallery items are nested within this 12-column section, we should specify that they take up 3 columns out of 12 (rather than 16).

The above code gives us this layout at desktop sizes:

Desktop view of our webpage34
Desktop view of our webpage. (View large version35)

Here’s the CodePen for this responsive layout.

See the Pen Responsive layout with Susy36 by Michelle Barker (@michellebarker372819) on CodePen382920.

Responsive layout with Susy (on CodePen)

Dealing With Sub-Pixel Rounding Link

If you’re working with percentage-based grids you’re going to come up against sub-pixel rounding issues. These occur when percentages result in column widths that subdivide a pixel, so the browser rounds your column width up or down by a pixel to compensate. This may mean your layouts don’t always behave as you might expect. For a full explanation of sub-pixel rounding, read “Responsive Design’s Dirty Little Secret39” by John Albin Wilkins.

Susy provides a workaround for dealing with sub-pixel rounding via its isolate technique40, and it’s a handy port of call when your layouts aren’t playing nice.

Conclusion Link

I hope this article has helped you get started with Susy and provided a small taste of what is possible. Once you spend a little time getting the hang of it, you’ll see how easy and fast it is to create simple or complex layouts without a huge amount of code; and it really will save you time in the long run.

Here are some useful links and resources to help you get started with Susy:

(ds, ml, og)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18 ''
  19. 19 ''
  20. 20 ''
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27 ''
  28. 28 ''
  29. 29 ''
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36 ''
  37. 37 ''
  38. 38 ''
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44

↑ Back to top Tweet itShare on Facebook

Michelle Barker is a designer and illustrator at Future Insights, where she supports the team crafting awesome conference experiences with her passion for web and print design. When she’s not tinkering with CSS or reading up on the latest design thinking, she can usually be found baking cakes, hanging out with her cat or enjoying a pint of real ale.

  1. 1

    Vadim Makeev

    July 20, 2015 3:07 pm

    It would be good to mention that Susy could be also installed via bower:

    bower install susy

    …and imported like this:

    @import ‘bower_components/susy/sass/susy’;

    • 2

      Michelle Barker

      July 20, 2015 3:59 pm

      Thanks Vadim – there are indeed many ways to install Susy :) I concentrated on a Compass example as I didn’t want to spend a huge amount of the article covering different installation methods. But all are equally valid, which is one of the great things about Susy! Thanks for mentioning :)

      • 3

        Vadim Makeev

        July 20, 2015 11:42 pm

        I mean that you’re may be familiar with Ruby, gem and the whole system around it. But I’m not and typical web developer either. We would rather install it via Node.js-based package manager (npm or bower) since building process is already involving Grunt, Gulp or something similar. I would also agree with Hugo Giraudel on “Why I Don’t Use Compass Anymore”

        The key idea behind my comment: Sass is not about Ruby anymore for the most of its users, so it’s better not to assume that gem install whatever would be a good way to go.

        • 4

          Michelle Barker

          July 21, 2015 10:03 am

          Susy was originally designed to work with Compass, so it made sense to me to use that as an example, but I didn’t mean to imply that was the only (or the best) way. I’m thinking of making the switch to Grunt + Libsass too.

    • 5

      Great post and great tips. I’ve been using the Susy grid system for quite a while now, for rapid prototyping but also in production. I feel the output of the code is clean and simple enough! Susy also works great with breakpoint sass and even has a syntax for use with breakpoint-sass specific. It also seems to have its own media query mixin, although I can’t find much about that in the documentation.

      To clarify my tweet about the speed though, it’s the only thing I’m wary of. Using Libsass, every span mixin adds about 20ms to the compile time (using Ruby sass, about 100ms per span). This doesn’t have to be a problem for everyone, but I’d advice to be careful with the amount of spans.

      • 6

        Michelle Barker

        July 21, 2015 9:01 am

        Thanks Arden! I haven’t used Breakpoint for media queries yet but it’s something I want to try out.

        I hadn’t realised that the span mixin gives such a hit to the compile times, even with Libsass. It’ll certainly make me more considerate of the number of spans I use. Although, as I mentioned in the tweet, it’s a sacrifice I’m willing to make for the time it saves me in coding, personally :)

      • 7

        Jack Quarry

        July 23, 2015 4:17 pm

        @Arden While using breakpoints with Susy, How do you put all your media queries together?
        Do you copy them manually or is there a better way?


        .myClass01 {
        @include breakpoint(max-width 768px){

        .myClass02 {
        @include breakpoint(max-width 768px){

        /* This would produce two different media queries in the compiled CSS although, they are for the same constraints i.e.max-width 768px */


  2. 8

    Scott Keller

    July 20, 2015 4:29 pm

    I’d also recommend looking at Bourbon Neat (

  3. 9

    > it really will save you time in the long run

    No, actually it really will be a huge time sink in the long run. You have yet another tool, which gets out of date, stops being supported, has another weird syntax, is something else the new guy doesn’t know and has to learn, is incompatible with something else, has bugs, requires new environments like Ruby, cannot be debugged, and so on ad infinitum. All this for something which is actually not all that hard to do in plain old CSS, believe it or not.

    • 10

      Tarik Hamilton

      July 20, 2015 6:18 pm

      I have to agree, you can easily just use Bootstrap’s Sass version and strip out everything but the grid.

    • 11

      Matthew Trow

      July 20, 2015 8:10 pm

      Totally agree with this.

      Learn how to roll your own grids (it’s not rocket science) and above all else, *examine* the CSS output after preprocessing.

      The CSS bloat you can end up with, using Susy, without first understanding the concept of grids, can quickly mount up.

      This article also demonstrates ‘gridding up’ aside and article tags. Not a good idea. Leave the structure to div tags, use semantic html tags for the purpose they were defined for.


      In an example above, the aside tag has been assigned span(4 last).
      How do you break out of that pattern?
      Two ways, you either nest the aside inside a specific class, or throw more classes into it.

      Yes, I know it’s an example, but it’s bad practice. *never* declare such specifics for semantic tags.

      • 12

        Michelle Barker

        July 21, 2015 9:28 am

        Some good points, and I agree it’s not necessarily the right choice for everyone 100% of the time. There are always reasons to use a new tool or not within a team, and at the end of the day you have to weigh up whether it’ll benefit you.

        My article was definitely written from a designer’s point of view – the main point being that having a tool like Susy allows me to spend more time on design, rather than fiddling with layout. I find it more flexible and less prescriptive than Bootstrap.

        The same goes for creating your own custom grid framework – I can see the benefits, but it is not necessarily the best use of my time when tools like Susy are readily available and do everything that I (currently) want.

        I agree you should always examine the CSS output when using a preprocessing tool, and understand CSS before jumping into something like Susy :)

    • 13

      July 20, 2015 8:18 pm

      You don’t need Ruby. It works fine with Libsass.
      Apart from that, every web dev should be familiar with a couple of grid systems, not just Bootstrap.

    • 14

      Thore Cardel

      July 23, 2015 2:55 pm

      I totally agree. It’s crazy how many tools there is for a preprocessor like Sass. I just made my own Sass-based responsive grid system. Then I get it totally how I prefer it.
      If anyone’s interested:

    • 15

      I fully agree! it’s a grid system that tries to do far too much and absolutely misses the point. Worst part is everyone has a different understanding of how it works.

      I highly recommend + selectivzr for ie8 support. You can include the scss version in your project so you don’t have to worry about updates etc. Best of all its stupidly simple and anyone can understand it if they’ve worked with SASS in the past

  4. 16

    I am still not sold on so called grids on demand. Be it Susy, Neat or Flint, I am not sure if there are any advantages to classical use, other than not polluting HTML with weird name classes.

    As for the code bloat, if you use many rows and columns, the generated CSS will outweight the styles needed for pure CSS grid. It is written once and you just use classes.

    While it is nice to separate things from markup and use mixins, I don’t see what is wrong with this:

    This way I can clearly see in my markup that this one spans 12 columns on mobile, 8 on medium break-point and 6 on large break-point.

    On a side note, check Flint grid system, some nice things in there, better than Susy or Neat, IMO.

  5. 17

    I use Jeet, it is a much more concise grid library. I have used Susy and Neat in the past but Jeet won out.

    I am a strong proponent of eliminating the html selector overload, its the main reason I switched to libs over pre-branded, bloated frameworks like Bootstrap and Foundation.

    • 18

      I absolutely agree! Susy looks good but I can’t recommend Jeet enough. That with Breakpoint Sass is very powerful, very quick, and very flexible. Wins hand down in my book.

  6. 19

    My number one problem with traditional grid frameworks has been when it comes to responsive design and breakpoints. You either use a few breakpoints and end up with columns that change at sub-optimal window sizes, or you get an increasingly larger jungle of classes each time you add a breakpoint.

    With Susy I can check and see that this content will break at 1056px, so then we add a breakpoint right there. Quick, easy, and no bloat.

  7. 20

    Hello Michelle, great article thank you. I used Susy a few years ago but moved away from it, however it seems more robust now, or you just did a better job explaining it than I did figuring it out. I’m just curious about one thing, is your use case for Susy in this way just for quick prototyping or do you mean for it to be used in production as well? I see a lot of issues using it this way in production, and therefore lean towards the comment Mirko made, just using grid classes. They can be really frustrating sometimes, so I’d love to hear how/if you use Susy production. I have a hard time believing you’re directly styling header, article, aside, li etc.

    • 21

      Michelle Barker

      July 21, 2015 9:55 am

      Hi Nate, thanks for your comment :) From what I understand Susy 2.0 has moved on quite significantly from Susy 1.0, so could be worth another go!

      In this article I’m mainly talking from a prototyping perspective, I wouldn’t use it 100% this way for production, but unless I’m working on small sites I would generally rely on a developer to help make my code production-worthy :) I generally use BEM for classes, I don’t really use grid classes but would be interested in learning how others use these effectively. One of the reasons I find Susy a more flexible alternative to Bootstrap is that you don’t need to declare these classes in your markup, but I would normally have a less prescriptive class for layout. While I’m designing I like to have the flexibility to alter something by one column width, for example, and not have to change it in two places, or essentially write my own framework!

      Not claiming I have all the answers, and I’m definitely interested in hearing from developers about the best way to do these things :)

  8. 22

    Great article

  9. 23

    < Bourbon's Neat

  10. 24

    Why not use flex box? Simple native grid system for CSS.

    • 25

      Flexbox is great if you are developing for IE 11 +. If your project calls for IE 10 and below then Flex is not a good path to take.

    • 26

      Michelle Barker

      July 24, 2015 3:22 pm

      Flexbox is great, but it’s not quite the same thing – as I mentioned in the article, you still have to write quite a bit of code, and you can’t do things like specifying gutter width, unless you write your own mixins. Susy (and other frameworks) make creating grids much quicker. That said, I would LOVE to see Susy support flexbox, it would make it even more powerful!

  11. 27

    Karen Menezes

    July 24, 2015 2:53 pm

    Although I stay away from custom grids, the reasons are more than unsemantic classes. This issue can always be resolved with mixins, if using a preprocessor. My main gripe is that I often need to use more than floats. For e.g., I use inline-block layouting for a grid of thumbnails, when I need to center lone thumbnails on a single line (simply by declaring text-align: center on the parent). Or when I don’t wish to use nth-of-type to clear floats on 3 breakpoints. Sometimes, flexbox can be great for vertical centering, equal heights and much more. So each project includes more than just floating for layouting. I keep some simple mixins, like col-50-flt, col-25-flt, that I use if I need floats. It’s also nice to break out of the 12 column and 16 column mindset, and just think in terms of halves, thirds, fourths, etc.

  12. 28

    Great Article

  13. 29

    Don’t forget to use @include nobreak if you are using breakpoints and starting with @include full

  14. 30

    Kim Göransson

    August 6, 2015 1:28 pm

    Neat! Gotta try this one out in my next project. :) Thanks for the article!

  15. 31

    Michelle, thanks for writing this.

    There are a plethora of grid frameworks / libraries / systems out there and none we’ve worked with are as useful or efficient as Susy (2.2.3).

    The average folks who state they run with their own grid output are simply misguided. Susy is based on math and values your own process and workflow. If you’re using a BEM/SMACSS/etc. system the process is even smoother when transitioning from one developer to the next. With more control, asymmetrical grids and so on, there’s more control at your finger tips and less bloat as previously described. Performance has never been a critical roadblock with cleanly written code.

    The only other comparison is Bootstrap 4 which is currently in alpha stage and has greatly caught up in being a neutral tool for rapidly building prototypes and so forth.


↑ Back to top