mediamonks / frontend-coding-standards

Media.Monks - Frontend Coding Standards
60 stars 23 forks source link

How to nest mediaqueries in SCSS? #14

Closed pigeonfresh closed 3 years ago

pigeonfresh commented 4 years ago

In general I have seen three ways how we organise our styles in combination with mediaqueries. I'm curious how others prefer handling this:

Method A:

.wrapper {

  .title {
    font-size: 1rem;
    @media (min-width: 1024px) {
      font-size: 2rem;
    }
  }

  .box {
    background: blue;
    @media (min-width: 1024px) {
      background: red;
    }
  }
}

Method B:

.wrapper {
  .title {
    font-size: 1rem;
  }

  .box {
    background: blue;
  }

  @media (min-width: 1024px) {
    .title {
      font-size: 2rem;
    }

    .box {
      background: red;
    }
  }
}

Method C:

.wrapper {
  .title {
    font-size: 1rem;
  }

  .box {
    background: blue;
  }
}

@media (min-width: 1024px) {
  .wrapper {
    .title {
      font-size: 2rem;
    }

    .box {
      background: red;
    }
  }
}
ThaNarie commented 4 years ago

Method B and C are similar, just a small stylistic difference of including the wrapper or not. The biggest difference is between A and B/C.

Both have their advantages, which change or become irrelevant depending on your other CSS.

The most mentioned benefit of method A is that in big files, you have all your styles together. If you work on an element across different breakpoints, all those styles are close together, which makes it easier to see what happens, or make changes. The downside is that you have to repeat the media queries a lot.

Method B/C have the benefit of grouping all overrides together, focussing on specific breakpoints, and their combined differences. The downside is that you have to duplicate (most of) the nesting structure in each breakpoint. That, and the fact that elements are split up in multiple places, makes refactoring (and just adding/removing elements) a bit trickier.

On smaller files, the downside of method B/C is minimal, since there isn't much scrolling to begin with

When using styled-components, you almost never use nesting, and your breakpoints should exist within the component itself, so you automatically end up with method A.

masaroli commented 4 years ago

I used to use C but then I switched to A. With B/C methods I find it hard to apply minor scss changes like padding in different views as I have to scroll to compare values

pigeonfresh commented 4 years ago

styled-components ftw. B/C are quite similar, but for consistency it might be something to consider picking one over the other. So worth mentioning. I've worked both with A and B. And I have a preference that might relate to how I personal approach my development.

If we feel it's okay to mix and match it based on personal preference I'm fine with that. I was curious what others used/prefered.

nswaldman commented 4 years ago

It depends on the project, sometimes even the very component. If the styling is simple enough and/or doesn't have a whole lot changes per breakpoint, A makes more sense. When sufficiently complex and the majority of elements gets affected by breakpoints, B is the more legible option.

pigeonfresh commented 4 years ago

I personally like to use multiple imports for even small components in projects. This will result in a hybrid between A and B. I think option A makes sense if you are focused on element styling and B if you move from breakpoint to breakpoint. In breaking up components in smaller bits (edit: using multiple imports of partial scss files) you will have an A-ish approach that has the benefits of grouped overwrites. But again: Interested in what others use and prefer.

thomas-media-monks commented 4 years ago

With scoped CSS I use method C minus the nesting. Otherwise I prefer method B as I look at a component as a whole, not individual elements within it. To me it makes me more sense to group all the changes to a component per breakpoint so you get a better overview of how it changes on each specific breakpoint.

Typically once I start adding breakpoints I copy paste the contents of my SCSS file within the newly added breakpoint and start adding/removing properties and selectors as needed. This way they are also in the same order which makes comparing them easier when you know your .title for instance is always the first selector per breakpoint.

Also tend to break up into sub components if a SCSS file becomes too long. In my current project for instance, my longest file is 99 lines including breakpoints.

Miguel-Bento-Github commented 3 years ago

I feel like option B and C increase the amount of code and make code harder to read

.selector {}

media-query {
  .selector {}
} 

in option A the media-query is already related to the selector

.selector {
  media-query {}
}
Miguel-Bento-Github commented 3 years ago

@pigeonfresh should this issue be closed? Is there an outcome to this?