Managing Media Queries

Mar 13, 2016 |4,312 views

When building complex sites your SCSS or LESS files can quickly become bloated and disorganised making future updates and adjustments very difficult and time consuming. Sticking to a preset structure can really help avoid these issues.

There are usually two approaches to managing media queries in SCSS / LESS:

1. Combined media queries: have a media query for a specified size listed only once in the stylesheet. Inside it, place all styles for components when viewed at this media query.

2. Component based / inline media queries: media queries are contained inside the relevant component (such as the header, or sidebar).

#Combined media queries

.site_header {
  padding: 2em 5%;
}
.site_footer {
  font-size: 2rem;
}
//other components
 
@media (min-width: 500px) {
  .site_header {
    padding: 2em 10%;
  }
  .site_footer {
    font-size: 1.6rem;
  }
  //other components
}

.site_header {
  padding: 2em 5%;
}
.site_footer {
  font-size: 2rem;
}
//other components
 
@media (min-width: 500px) {
  .site_header {
    padding: 2em 10%;
  }
  .site_footer {
    font-size: 1.6rem;
  }
  //other components
}

Combined media queries can work well for simple adaptive* sites that have changes to multiple components when the viewport reaches a specific size. Often these sites have few media queries.

*For more information on the difference between adaptive, responsive, and liquid layouts be sure to check out liquidapsive.com

The problem? Updates and maintenance.

Imagine you’ve built a site and it looks great, but now you need to completely change the layout of a component, say the header for example. If there are 5 media queries that change the header layout you will need to go to 5 different locations in your SCSS / LESS file.

Depending on the size of the website these class declarations, found in various media queries, may be separated by hundreds of lines of CSS. Additionally if you use separate stylesheets for different screen sizes you’ll have to open multiple files.

By having the styles for a single component fragmented across your SCSS / LESS file (or even in multiple files) it slows down development time, particularly when debugging or making adjustments. It’s rarely the case that components change their layout at the same media query as other components, especially with more complex layouts.

#Component based / inline media queries

.site_header {
  padding: 2em 5%;
 
  @media (min-width: 500px) {
    padding: 2em 10%;
  }
}

.site_header {
  padding: 2em 5%;
 
  @media (min-width: 500px) {
    padding: 2em 10%;
  }
}

Components should be treated as modular individual organisms that work together to form larger systems of components. To this effect different components will have individual requirements and need individual media queries.

This approach will also facilitate content driven media queries, as opposed to device driven media queries, to create the best experience. It allows components to change layout based on their own respective content and size.

If changes do need to take place across separate components at the same media query, simply match the value of the media query, or create a variable value for that breakpoint, to use throughout multiple components:

$large_bp: 900px;
 
.site_header {
  padding: 2em 5%;
 
  @media (min-width: $large_bp) {
    padding: 2em 10%;
  }
}

$large_bp: 900px;
 
.site_header {
  padding: 2em 5%;
 
  @media (min-width: $large_bp) {
    padding: 2em 10%;
  }
}

By keeping all the styles for a single component in one block it gives us the following benefits

• The development of components is less fragmented
• Reduction in specificity issues
• Code is more maintainable and easy to update
• Easier for other developers to use, who may be new to the project
• Gives greater opportunity for multiple developers working simultaneously on building CSS components
• As a result the build process is often clearer and quicker

Top web developers advocate this approach, people like Chris Coyier, Harry Roberts and the folks at Sparkbox. It is also encouraged by some of the most popular front end development guidelines — Block Element Modifier and CSS Guidelines.

This approach still warrants careful consideration in structuring your SCSS / LESS components. If you’re not careful media queries could be scattered all over components, making future updates confusing and messy. My preferred SCSS / LESS component structure is to set the component base styles first, then modifiers, then responsive changes, like so:

/* — — — — — — Hero — — — — — — -*/
.hero {
  width: 100%;
  height: 400px;
  position: relative;
 
  .callout {
    padding: 2rem;
    .title {
      font-size: 3rem;
    }
  }
 
  /*modifiers*/
  &.hero--highlight {
    .callout {
      background: papayawhip;
    }
  }
 
  /*responsive*/
  @media (min-width: 500px) {
    .callout {
      padding: 3rem;
      .title {
        font-size: 4rem;
      }
    }
  }
 
  @media (min-width: 830px) {
    .callout {
      padding: 4rem;
      .title {
        font-size: 5rem;
      }
    }
  }
}

/* — — — — — — Hero — — — — — — -*/
.hero {
  width: 100%;
  height: 400px;
  position: relative;
 
  .callout {
    padding: 2rem;
    .title {
      font-size: 3rem;
    }
  }
 
  /*modifiers*/
  &.hero--highlight {
    .callout {
      background: papayawhip;
    }
  }
 
  /*responsive*/
  @media (min-width: 500px) {
    .callout {
      padding: 3rem;
      .title {
        font-size: 4rem;
      }
    }
  }
 
  @media (min-width: 830px) {
    .callout {
      padding: 4rem;
      .title {
        font-size: 5rem;
      }
    }
  }
}

The future…

Finally, component based media queries are more inline with atomic design and content driven media queries. It’s also where the future of responsive web development is heading.

Pretty soon we’ll have element / container media queries which will allow components to change layout based on their own respective size, not based on the width or height of the viewport. When this is widely supported it will make component based SCSS / LESS even more modular and even more awesome!

Wrapping up

Using component based media queries has made my workflow more efficient, clearer and easier to maintain. If you aren’t already doing it, I’d highly recommend giving it a try. As always your mileage may vary. So if combined media queries work better for you and the projects you work on, then keep doing it!