How Sass Can Simplify Responsive Design

I had the wonderful opportunity to talk about my experiences developing a major responsive website redesign last weekend at The Mixin, a Sass-focused meetup organized by Jina Bolton, product designer at Do. It was kindly hosted by Moovweb, the company founded by Hampton Catlin, inventor of Sass (and Haml). The star of the show was Chris Eppstein, Compass creator, Sass maintainer, and everyday lifesaver, who showed us the hot stuff in the pipeline for Sass 3.3 and beyond.

Slides

  1. You can view the slides on Slideshare. Or…

  2. Download the slideshow as a PDF. (7MB. Alternate link.)

No video was made of the event.

Some Written Notes

Below are notes that will provide a little more background than the slides. I would recommend taking a look at both, if this is the sort of thing in which you are interested.

Context

Redesigning a large web app with significant traffic. We wanted a mobile-friendly experience using responsive design, but did not want to break compatibility with IE8+.

Keep it DRY: Different stylesheet builds

Because some browsers just can’t handle the modern CSS3 and HTML5 techniques we needed to pull off a polished responsive design, we needed to give them non-responsive, fixed-width CSS.

What was the solution?

  • One Sass codebase
  • Two top-level Sass files. They:
    • Set global configuration variables, and/or
    • Include or exclude certain parts of your codebase

Result: Two CSS file builds with no unnecessary or unwanted styles.

Possible thanks to Sass 3.2

In Sass 3.2, we gained the ability to pass content in to mixins. I demonstrate this in the slide show.

An Example

Sass (.scss):

@mixin mobile {
  @if $responsive {
    @media(max-width: 320px) {
      @content;
    }
  }
}

@mixin desktop {
  @if $responsive {
    @media(min-width: 960px) {
      @content;
    }
  }
  @else {
    @content;
  }
}

.btn-primary {
  cursor: pointer;
  background-color: $corp-blue;
  @include mobile {
    width: 100%;
  }
  @include desktop {
    font-size: 1.2 * $font-size;
  }
}

In app-responsive.css.scss:

$responsive: true;

Compiled app-responsive.css:

.btn-primary {
  cursor: pointer;
  background-color: #0090f2;
}
@media (max-width: 320px) {
  .btn-primary {
    width: 100%
  }
}
@media (min-width: 960px) {
  .btn-primary {
    font-size: 19px; 
  }
}

In app-fixed-width.css.scss:

$responsive: false;

Compiled to app-fixed-width.css:

.btn-primary {
  cursor: pointer;
  background-color: #0090f2;
  font-size: 19px; 
}

Notes

  • Missing: A “Tablet” breakpoint (and corresponding mixin).
  • Code simplified a bit here.
  • I used Susy. It’s great! Check it out!
  • Oh, I used Compass, too — I almost forgot to mention that, since it’s so obvious than anyone using Sass should be using Compass.
  • The technique of compiling multiple versions of a stylesheet from one codebase also works if you have two sites with a lot of shared code. One is your marketing / company site; the other is a full web app, say. I did this when I maintained the Simplenote web properties. Similarly, if logged-in users can do a lot more than visitors, you may want to deliver styles to them differently.

What Didn’t Work

  • IE9 cannot size SVG responsively
 (width: 100%; height: auto only works on rasters). Ended up writing a helper in Rails that would issue PNG to IE ≤ 9 and SVG to other browsers.

  • IE9 lack of support for input placeholder="..." led to bugs when we tried using JS to apply placeholder attributes only on mobile, thanks to fighting between the placeholder shim/polyfill and our breakpoint-handling JS.

  • Possible to solve issues like the above, but in the interest of time and because IE is not much used on mobile devices, we shipped responsive without IE9 support.

  • One approach I tried was compiling one CSS version with “responsive” and “fixed-width” versions in the same file, by prefixing selectors with .responsive and .fixed-width, respectively; but I had major issues in IE8 with this approach, for whatever reason that was not worth my time. And I did not want the extra specificity that approach added.

SMACSS

The slides discuss challenges issuing from attempting to apply SMACSS to responsive design. The core challenge is that the idea of “a class name representing layout” breaks down when layout changes across breakpoints. (And this is further complicated because it is not possible to extend things from within an @media context without significant work or duplication; but Chris is working on making this situation much butter in Sass 3.3 and beyond!)

If you don’t know what SMACSS is, you can read about it on the official site. It’s a great methodology.


June 28th, 2013. (Updated: July 06, 2013 at 9:02pm.)
Alan Hogan (@alanhogan).  Contact · About