1

Throughout my stylesheets I have calls to span, using Susy's mixins to control the widths of the numerous modules used across a site.

I now have a requirement to change the grid gutter width at a given breakpoint. Whereas with a traditional grid system like the one one used by Foundation, all I would need would be a media query like this (assuming I has used classes on the elements):

@include breakpoint($medium-up) {
   .column, .columns
   {
      padding: 6rem;
   }
}

I can't see how to do the same thing using Susy. All my grid styling is now provided through mixins, so I no longer have clear hooks to target the spans.

How can I switch gutter widths at a breakpoint without resorting to adding individual breakpoints for each place I've used span?

From Susy's documentation it seems the answer is to add something like:

.example {
    @include span(6);

    @include susy-breakpoint($medium-up, $medium-up-layout) {
       @include span(6);
    }
}

But repeating this across all my modules seems like a lot of duplication.

Of course, this problem isn't limited to Susy. The same issues arise using Compas's Vertical Rhythm. As soon as the rhythm needs to change at a breakpoint, the only option is to explicitly declare the change in a breakpoint at each and every point vertical rhythm's functionality is used.

In both cases - horizontal layout and vertical rhythm, it seems that a layer of abstraction is needed to allow for centralised changes to propagate across modules and avoid proliferation of duplicated media queries.

To be clear, I'm in no way criticising either toolkit. Just looking for the best way to use them.

Undistraction
  • 42,754
  • 56
  • 195
  • 331
  • I am having the exact same issue thinking through how I would approach things! Don't want to have to repeat so many things – Damon Jan 26 '15 at 15:08

1 Answers1

2

Susy was never intended to dictate how you work, so if you don't like Susy's approach to gutters, set the gutters setting to null, and handle them exactly like you would in Foundation. Susy can't build that in, because we are strict about staying out of your markup — but you could easily build foundation-style grids using Susy to handle the math. If that's what you like, go for it! 

.column, .columns {
  padding: 3rem;

  @include breakpoint($medium-up) {
    padding: 6rem;
  }
}

That just means you'll have to use the column class all over your markup. It's a trade-off.

You can also simplify the way you are handling it with Susy. If gutters are the only thing you need to change, you can cut down more on your output:

.example {
  @include span(6);

  @include susy-breakpoint($medium-up, $medium-up-layout) {
    @include gutters();
  }
}

And if you want to cut down on your input, you can wrap it in a mixin:

@mixin gutter-change() {
  @include susy-breakpoint($medium-up, $medium-up-layout) {
    @include gutters();
  }
}

.example {
  @include span(6);
  @include gutter-change;
}

From the research I've seen, repeated media-queries in the output don't add relevant load-time to CSS, as long as you are delivering gzipped assets.

Miriam Suzanne
  • 13,632
  • 2
  • 38
  • 43
  • Please don't get me wrong. I love Susy's approach. Just finding it difficult to find the right way to use it. I think a big part of the problem (for my understanding and so far as I've seen it the understanding of others) is trying to decouple the idea that Susy ( and Sass ) are dynamic in so far as they are able to propagate reactions to breakpoints throughout previously declared selectors. In an OO language it would make sense that a trigger could alter state throughout a program, whereas with Sass, this is not the case. Thanks for replying. Its late here & I'll process this in the morning. – Undistraction Jul 25 '14 at 23:47
  • Thanks. This makes sense. I don't want to replicate Foundation, just to understand how to do the same thing using Susy. I suppose the pattern in all this is to package cross-breakpoint functionality into mixins and take the hit on the repeated media-query output. So effectively ask the breakpoint for gutters and have it return a set of queries manipulating the gutters across breakpoints. – Undistraction Jul 26 '14 at 09:08
  • Well, replicating Foudantion with Susy *is* part of how Susy is supposed to work. The entire goal of Susy (unlike Foundation and others) is that you can pull it apart and do things your own way, rather than trying to fit into my way of working. The thing you are noticing about Sass comes from the fact it's a *pre-processor* for CSS — so it has no way to access the DOM. Because of the way CSS cascades with the DOM, it would be impossible for Sass to reliably do the sort of magic you would expect from OO programming languages. – Miriam Suzanne Jul 26 '14 at 20:38
  • I think my problem is I'm so used to functional and OO languages, I find it hard to shake the mindset, even if its in the form of niggling assumptions in the background. – Undistraction Jul 26 '14 at 22:27