Breakpoints and Tweakpoints in 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:

[code language="sass"] // 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; } } [/code]

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 %Breakpoints and Tweakpoints in Sass%

by Hugo Giraudel via SitePoint