Breakpoints and Tweakpoints in Sass

Originally published at: http://www.sitepoint.com/breakpoints-tweakpoints-sass/

A while back I, here on SitePoint, wrote Managing Responsive Breakpoints with Sass, presenting a couple of ways to deal with responsive design breakpoints using variables and mixins.

The last solution I introduced relies on a map of breakpoints, usually stored in the configuration file and a mixin taking a breakpoint name as the only argument, outputing a media query block. It should look like this:

// In `_config.scss`
$breakpoints: (
  'small'  : 767px,
  'medium' : 992px,
  'large'  : 1200px,
) !default;

// In `_mixins.scss`
@mixin respond-to($breakpoint) {
  @if map-has-key($breakpoints, $breakpoint) {
    @media (min-width: map-get($breakpoints, $breakpoint)) {
      @content;
    }
  }

  @else {
    @warn "Unfortunately, no value could be retrieved from `#{$breakpoint}`. "
        + "Please make sure it is defined in `$breakpoints` map.";
  }
}

// In `_random-component.scss`
.foo {
  color: red;

  @include respond-to('small') {
    color: blue;
  }
}

This solution is perfectly fine for many projects, from small to medium scale. Yet, when we start to have many components, it tends to fall a bit short.

Indeed, we can make a distinction between two different kinds of breakpoints:


  • actual breakpoints, involving layout recomposition;

  • component-specific breakpoints, helping polishing the look and feel of the page.

Continue reading this article on SitePoint

1 Like

Just thought I'd mention that I've implemented this on a site I'm working on and it seems to work like charm. The only heads up is that if you @import your Sass-files like this:

  1. _config.scss
  2. _mixins.scss
  3. _component-1.scss
  4. _component-2.scss

...and you have a breakpoint-mixin doing some work in _component-1.scss (but only accessing the global $breakpoints list) and the same mixin accessing a local $tweakpoints-map in _component-2.scss, you'll get a Sass compile error if you don't instantiate an empty $tweakpoints-map in _config.scss. This is because the variable needs to exist the first time the mixin gets called.

Awesome idea Hugo – it really cleans up the global $breakpoints-map and makes my BEM-style .scss-files even more encapsulated and self-governed, without loosing the benefits of a global, shared breakpoint-map.

@Hugo Super cool idea, well done thumbsup

I want to start using this mixin right now, but I'm not sure what's the best way for naming tweakpoints, so it won't become confusing and frustrating in the future...

Should they be named by the property they tweak ? Can you give some general recommendations on naming tweakpoints? Maybe some examples.

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.