Reducing redundancy in output of the semantic grid columns system

[dschenk]

I often have the following use case when generating semantic columns:

.module {
  .make-xs-column(12);
  .make-sm-column(6);
  .make-md-column(3);
}

Meaning I need a class that fills a variable amount of columns, depending on breakpoints.
Before this patch, the code above would generate the following CSS:

.module {
  position: relative;
  min-height: 1px;
  padding-left: 15px;
  padding-right: 15px;
  float: left;
  width: 100%;
  position: relative;
  min-height: 1px;
  padding-left: 15px;
  padding-right: 15px;
  position: relative;
  min-height: 1px;
  padding-left: 15px;
  padding-right: 15px;
  margin-bottom: 24px;
}

@media (min-width: 768px) {
  .module {
    float: left;
    width: 50%;
  }
}

[etc. for the other media-queries]

I propose to use the grid system in the following way to reduce this redundancy:

.module {
  .make-column();
  .make-xs-column(12);
  .make-sm-column(6);
  .make-md-column(3);
}

or:

.module {
  .make-column();
  .make-md-column(3);
}

This means using the make-column mixin whenever we want to define a semantic column class. In my opinion this disadvantage beats redundant output though.

Your thoughts?

[cvrebert]

So then there's no point in having the @gutter parameter.

[dschenk]

True. Using the system in the following way

.module {
  .make-xs-column(12, 10px);
  .make-sm-column(6, 20px);
  .make-md-column(3, 30px);
}

Did not make sense before the patch. It would just output and use the last given gutter (30px).
If somebody would want to use a custom gutter width she or he could do the following:

.module {
  .make-column(30px)
  .make-md-column(3);
}

We can remove the gutter params for the make-[bp]-column mixins then, right?

[dschenk]

@cvrebert What do you think?

[cvrebert]

It's a good idea, but seems like it would break backwards compatibility for mixin-users.

[mdo]

Super into this though. I realized I screwed up the mixins far too late. Will slate for v4.