Skip to content
This repository has been archived by the owner on Feb 15, 2020. It is now read-only.

Sass order #65

Closed
maya opened this issue Nov 30, 2015 · 6 comments
Closed

Sass order #65

maya opened this issue Nov 30, 2015 · 6 comments

Comments

@maya
Copy link
Contributor

maya commented Nov 30, 2015

I was looking at Thoughtbot's order section of their Sass styleguide https://github.com/thoughtbot/guides/tree/master/style/sass#order:

  • Use alphabetical order for declarations.
  • Place @extends and @includes at the top of your declaration list.
  • Place media queries directly after the declaration list.
  • Place concatenated selectors second.
  • Place pseudo-states and pseudo-elements third.
  • Place nested elements fourth.
  • Place nested classes fifth.
.class-one {
  @include mixin;
  background-color: $color-variable;
  border: 0;

  @include media($small-screen) {
    margin: ($spacing-variable * 2) 1rem;
  }

  &::before {
    content: "hello";
  }
}

18F's:

Follow ordering:

  1. variables
  2. @extend directives
  3. @include directives
  4. properties
.module {
  $amount = 3;
  @extend .component;
  @include sizing($amount);
  margin-top: $amount * 1em;
  text-align: center;

  .module__ele {
    color: #fff932;
  }

  @include media($sm) {
    margin-top: ($amount + 10em);
  }
}

Do we have any guidance for ordering of concatenated selectors, pseudo-states and pseudo-elements, nested elements, nested classes?

Based off our example it seems like we place media queries at the end of everything. What's the thought behind that?

@msecret
Copy link
Contributor

msecret commented Dec 2, 2015

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
Copy link
Contributor

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
Copy link
Contributor Author

maya commented Dec 5, 2015

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
Copy link
Contributor

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
Copy link
Contributor Author

maya commented Dec 5, 2015

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
Copy link
Contributor

msecret commented Dec 11, 2015

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants