Sass order

[18f]

Sass order

[msecret]

I think it should be something like this:

• Include @extend and @include at the top unless the @include has nested data, such as bourbon's media ones.
• Place @include's with nested data after all declarations.
• Place pseudo-states and pseudo-elements third.
• Place nested elements fourth.
• Place nested classes fifth.

[noahmanger]

Yeah, I think I like Thoughbot's guidance on this one. If you're going to nest media query @includes in the parent selector, I like having them right after the declaration list rather than at the end.

But I'm just gonna throw this in here: I've been starting to not like nesting media queries like that. If you have a Block (in the BEM sense) and various Elements within it and Modifiers of it, I don't like including media queries within each one because: a) it feels super repetitive and b) I have a much harder time reading through it to understand what happens to the Block component as a whole at the different break points.

So for FEC I've started instead breaking out the media queries and including them at the end of each components .scss partial, along with a short comment about what happens at the different breakpoints. For example.

What do people think about this? It works for me because our partials are really small and self-contained, and I find it just makes everything more readable.

[maya]

I'm also going to say that I think Thoughtbot is probably on the money with their ordering.

@noahmanger the way you described breaking out media queries into their own sections is how I remember people did it in the past, except it was for site-wide CSS, not component-level. I can see that there's a kind of clarity by having them separate. However, what I'm seeing nowadays is nesting them inside selectors. For example, this resource recommends nesting them inside: http://sass-guidelin.es/#media-queries-usage

As web design is getting much more about modular, independent HTML components, we'll have to keep asking what makes the most sense for this component-thinking.

[noahmanger]

Yeah, I'm seeing that recommended too... I just don't know if I agree :) .

I think if you have general classes that are shared by a lot of components, it makes sense to nest. But say, for example, you've got a component like this in a _foo.scss file:

.foo { }
.foo__element {}
.foo--big {}

Doing it this way feels cumbersome:

.foo {
  @include media($medium) { }
  @include media($large) { }
}

.foo__element {
  @include media($medium) { }
  @include media($large) { }
}

.foo--big {
  @include media($medium) { }
  @include media($large) { }
}

Whereas this feels more readable, to me at least:

.foo { }
.foo__element {}
.foo--big {}

@include media($medium) {
  .foo { }
  .foo__element {}
  .foo--big {}
}

@include media($large) {
  .foo { }
  .foo__element {}
  .foo--big {}
}

Even in doing it my way, the media queries are still very closely associated with the selectors they're applying. I agree that that's critical. I just think it gets hard to keep track of all the various ways that things change at different breakpoints if they're scattered throughout.

Very happy to be convinced otherwise. I just wanted to share my thinking.

[maya]

a) it feels super repetitive

But you just end up repeating on the selector instead. In your method, I can see myself ctrl + F -ing and trying to find the right selector, since it appears three times in your technique that might confuse me vs. just finding exactly the single selector I need and being physically close to all the changes via media queries.

[msecret]

@maya will write this into a styleguide, using language that insinuates this is a soft rule, and will create a PR.