The Sass Way

Avoid nested selectors for more modular CSS

2013-05-24T00:00:00+00:00

We’ve written before about the dangers of nesting your CSS selectors too deeply. The Inception Rule is a good one for getting you to avoid some mangled CSS selectors. But there’s actually a lot of benefit to taking this concept a couple of steps farther. What happens when you avoid nesting for almost all of your major selectors?

Contextual selectors

First, let’s talk about why this might be a good idea. One of the most powerful things about CSS is the ability to style elements differently based on different contexts. For example:

:::scss
.post {
  margin: 2em 0;

  .title {
    font-size: 2em;
    font-weight: normal;
  }
}

.sidebar .post {
  margin: 1em 0;

  .title {
    font-size: 1.2em;
    font-weight: bold;
  }
}

The code above is a basic example of how you might style a blog post differently based on whether it is within the sidebar or not.

At first this kind of contextual power may seem like a very good idea. You can use the same HTML in the sidebar of your site as you do in the main body of the site and get very different stylistic results.

But what happens when you want to use the styles that you’ve written for posts in your sidebar in an archive index or something similar? Whoops! Our contextual code will have to be updated for the new context.

Now Sass provides many powerful tools that can make sharing styles in different contexts easy, but this often comes with an added cost of complexity. If you care at all about writing maintainable code you will avoid complexity at all costs.

A more modular way

Let’s write these styles in a more modular way:

:::scss
.post {
  margin: 2em;

  .title {
    font-size: 2em;
    font-weight: normal;
  }
}

.summary {
  margin: 2em;

  .title {
    font-size: 1.2em;
    font-wieght: bold;
  }
}

Hot dog! That’s better. Now we’ve made our rules more generic and aren’t styling as much on context. We’ve got two separate CSS “modules” now. Post and summary. Summary can be used for sidebar items or in our archive index.

But we can improve this code further. The title class is still used in a contextual way. All it takes is for someone to declare a more generic title rule and your styles can be thrown off.

Clashing worlds

Suppose you decided to make a page title, and declared the rule like this:

:::css
.title {
  font-size: 3em;
  font-weight: bold;
  color: red;
}

Without thinking about how you’ve used title already in other contexts you’ve created a rule that will effect all other elements that also use a class of “title”. Now this example is a bit contrived, but in the real world this kind of style clash is common. On projects I’ve worked on in the past that use this style of coding it is a common occurrence that someone adds a new rule somewhere else that blows out styles in other contexts. On large projects these kinds of “bugs” can be hard to catch before code is moved into production.

So how can we simplify our code and at the same time add clarity? Like this:

:::css
.page-title {
  font-size: 3em;
  font-weight: bold;
  color: red;
}

// Posts
.post {
  margin: 2em 0;
}
.post-title {
  font-size: 2em;
  font-weight: normal;
}

// Summaries
.summary {
  margin: 1em 0;
}
.summary-title {
  font-size: 1.2em;
  font-weight: bold;
}

Ah! Much better! This minimizes the chance that other rules will clash with the ones we’ve just defined and helps ensure that our CSS modules will look the same in any context.

Context and modularity

The key word here is context. If you value modularity you will strive to avoid contextual styles. There are times when context can be useful. Responsive designs and themes often require them. But you should be very intentional when choosing to use contextual styles. If you use them without thinking you may find that your code is extremely hard to maintain and accidental bugs surface more regularly than you would like.

It’s also worth noting that if you find yourself using nesting regularly, you should consider if removing it could simplify your code.

Conclusion

Hopefully you don’t find these ideas too controversial. If you are interested in learning more about modular CSS I highly recommend taking a look at Jonathan Snook’s ebook on the subject and following Harry Roberts over at CSS Wizardry.

How to structure a Sass project

2013-04-03T00:00:00+00:00

One of the most useful features of Sass is being able to separate your stylesheets into separate files. You can then use the @import directive to include the source of your individual files into one master stylesheet.

But how should you structure your Sass projects? Is there a standard way of separating out your CSS files?

Basic directory structure

I like to layout my Sass projects like this:

:::text
stylesheets/
|
|-- modules/              # Common modules
|   |-- _all.scss         # Include to get all modules
|   |-- _utility.scss     # Module name
|   |-- _colors.scss      # Etc...
|   ...
|
|-- partials/             # Partials
|   |-- _base.sass        # imports for all mixins + global project variables
|   |-- _buttons.scss     # buttons
|   |-- _figures.scss     # figures
|   |-- _grids.scss       # grids
|   |-- _typography.scss  # typography
|   |-- _reset.scss       # reset
|   ...
|
|-- vendor/               # CSS or Sass from other projects
|   |-- _colorpicker.scss
|   |-- _jquery.ui.core.scss
|   ...
|
`-- main.scss            # primary Sass file

Primary stylesheet

This allows me to keep my primary Sass file extremely clean:

:::scss
// Modules and Variables
@import "partials/base";

// Partials
@import "partials/reset";
@import "partials/typography";
@import "partials/buttons";
@import "partials/figures";
@import "partials/grids";
// ...

// Third-party
@import "vendor/colorpicker";
@import "vendor/jquery.ui.core";

Modules, partials, and vendor

As you can see this divides my project into three basic types of files. Modules, partials, and vendored stylesheets.

The modules directory is reserved for Sass code that doesn’t cause Sass to actually output CSS. Things like mixin declarations, functions, and variables.
The partials directory is where the meat of my CSS is constructed. A lot of folks like to break their stylesheets into header, content, sidebar, and footer components (and a few others). As I’m more of a SMACSS guy myself, I like to break things down into much finer categories (typography, buttons, textboxes, selectboxes, etc…).
The vendor directory is for third-party CSS. This is handy when using prepackaged components developed by other people (or for your own components that are maintained in another project). jQuery UI and a color picker are examples of CSS that you might want to place in the vendor directory. As a general rule I make it a point not to modify files in my vendor directory. If I need to make modifications I add those after the vendored files are included in my primary stylesheet. This should make it easy for me to update my third-party stylesheets to more current versions in the future.

Using a base partial

In my partials directory you will also notice that I have a base partial. The purpose of this partial is to load up my Sass environment so that it’s easy to construct a stylesheet.

It might look something like this:

:::scss
// Use Compass ('cause it rocks!)
@import "compass";

// Font weights
$light: 100;
$regular: 400;
$bold: 600;

// Base Font
$base-font-family: sans-serif;
$base-font-weight: $regular;
$base-font-size: 13px;
$base-line-height: 1.4;

// Fixed Font
$fixed-font-family: monospace;
$fixed-font-size: 85%;
$fixed-line-height: $base-line-height;

// Headings
$header-font-weight: $bold;

@import "modules/all";

The base stylesheet sets a couple of global variables and loads up all of my Sass modules. Again modules are not allowed to contain anything that would cause CSS output when importing. Tying all of my varibles and modules up into a base partial gives me access to my entire Sass environment whenever I’m setting up a new stylesheet with a single import statement. This allows me to build multiple stylesheets by importing different partials. Multiple stylesheets are handy once a project grows to a certain size.

One step further

At UserVoice we take this pattern one step further. Since we have multiple sub-projects all bundled together in a single Rails app, we bundle each sub-project into a separate top-level directory. Our stylesheet directory looks more like this:

:::text
stylesheets/
|
|-- admin/           # Admin sub-project
|   |-- modules/
|   |-- partials/
|   `-- _base.scss
|
|-- account/         # Account sub-project
|   |-- modules/
|   |-- partials/
|   `-- _base.scss
|
|-- site/            # Site sub-project
|   |-- modules/
|   |-- partials/
|   `-- _base.scss
|
|-- vendor/          # CSS or Sass from other projects
|   |-- _colorpicker-1.1.scss
|   |-- _jquery.ui.core-1.9.1.scss
|   ...
|
|-- admin.scss       # Primary stylesheets for each project
|-- account.scss
`-- site.scss

As you can see each sub-project has it’s own primary stylesheet, modules, partials, and base. Vendored stylesheets are typically versioned and have their own top-level directory. This is a handy pattern to use on very large Sass projects.

Further exploration

Now that I’ve laid out my own method for this, you may want to explore how other people have structured their Sass projects. There’s actually a lot of variation in what you can do here. And some methods may work better on different projects:

Also check out Dale Sande’s excellent article, Clean out your Sass junk drawer.

Responsive Web Design in Sass: Using Media Queries in Sass 3.2

2012-04-09T06:00:00-05:00

In Responsive Web Design in Sass Part 2 I wrote about using media queries in Sass 3.1. At the time, I was mostly limited to the (still very cool) @media bubbling feature. I also pointed out some of the shortcomings.

At the end of the post I previewed how you can use @content blocks, one of the emerging features of Sass 3.2, to write a mixin that can really help to simplify using media queries in Sass. With Sass 3.2 nearly upon us, I am happy to report that media queries have become the first-class citizens they deserve to be. Let’s see what’s new.

Variables in queries

If you tried to use a variable in the media query test in Sass 3.1 it would fail by simply spitting out the actual text of the variable name. This is fixed in Sass 3.2, and works pretty much as I always expected it would.

:::scss
$break-small: 320px;
$break-large: 1200px;

.profile-pic {
  float: left;
  width: 250px;
  @media screen and (max-width: $break-small) {
    width: 100px;
    float: none;
  }
  @media screen and (min-width: $break-large) {
    float: right;
  }
}

Compiles to:

:::css
profile-pic {
  float: left;
  width: 250px;
}
@media screen and (max-width: 320px) {
  .profile-pic {
    width: 100px;
    float: none;
  }
}
@media screen and (min-width: 1200px) {
  .profile-pic {
    float: right;
  }
}

Variables as full query

You’re not limited to using variables in the numerical part of a @media test. Go ahead and set the whole test as a variable. (Note the need for the interpolation braces #{})

:::scss
$information-phone: "only screen and (max-width : 320px)";

@media #{$information-phone} {
  background: red;
}

Compiles to:

:::css
@media only screen and (max-width : 320px) {
  background: red;
}

Variables on either side of the colon in a query

You can also get really abstract and set a variable for items on either side of the colon in a test. I can see this being very usefull in building flexible responsive frameworks.

:::scss
$width-name: max-device-width;
$target-width: 320px;

@media screen and ($width-name : $target-width) {
  background: red;
}

Compiles to

:::css
@media screen and (max-device-width: 320px) {
  background: red;
}

You can also do math on a variable in a query, like so:

:::sass
@media screen and ($width-name : $target-width + 1) {
  background: red;
}

Compiles to

:::css
@media screen and (max-device-width: 321px) {
  background: red;
}

Variables in queries, using @content

In Responsive Web Design in Sass Part 2, I illustrated how to write some nicely abstracted media query systems using @content blocks in mixins. Now you can take that a step further by using variables in the actual queries. I think this will be very helpful in refining a set of breakpoints.

On my next project, I think I’ll start with some of the usual device-related breakpoints (320, 480, 720) as “placeholder” breakpoints. Then as I progress in building my design I’ll alter those to whatever values suit my design.

SCSS

:::scss
$break-small: 320px;
$break-large: 1024px;

@mixin respond-to($media) {
  @if $media == handhelds {
    @media only screen and (max-width: $break-small) { @content; }
  }
  @else if $media == medium-screens {
    @media only screen and (min-width: $break-small + 1) and (max-width: $break-large - 1) { @content; }
  }
  @else if $media == wide-screens {
    @media only screen and (min-width: $break-large) { @content; }
  }
}

.profile-pic {
  float: left;
  width: 250px;
  @include respond-to(handhelds) { width: 100% ;}
  @include respond-to(medium-screens) { width: 125px; }
  @include respond-to(wide-screens) { float: none; }
}

CSS

:::css
.profile-pic {
  float: left;
  width: 250px;
}
@media only screen and (max-width: 320px) {
  .profile-pic {
    width: 100%;
  }
}
@media only screen and (min-width: 321px) and (max-width: 1023px) {
  .profile-pic {
    width: 125px;
  }
}
@media only screen and (min-width: 1024px) {
  .profile-pic {
    float: none;
  }
}

Nothing is Perfect

@extend within @media

There are features and optimisations I’d like to see regarding @media handling in Sass. For example @extend doesn’t behave like I’d expect when I use it in a media query.

When I write the Following in SCSS:

:::scss
.red {
  color: red;
  }

.blue {
  color: blue;
}

@media only screen and (max-width : 300px){
  .blue {
    @extend .red;
    margin: 10px;
  }
}

I intended for the generated css to look something like:

:::css
.red {
  color: red;
}
@media only screen and (max-width: 300px) {
  .blue {
    color: red;
  }
}

.blue {
  color: blue;
}

@media only screen and (max-width: 300px) {
  .blue {
    margin: 10px;
  }
}

But what I really got wasn’t nearly as useful.

:::css
.red, .blue {
  color: red;
}

.blue {
  color: blue;
}

@media only screen and (max-width: 300px) {
  .blue {
    margin: 10px;
  }
}

This is a hairy issue, and different use cases suggest different results. Eventually this may just be disallowed.

Combining @media Queries on Compile

One feature I hear a lot of people bring up with @media bubbling is that you often end up with the same query in many places in your compiled CSS. The resulting CSS would be much smaller and more closely resemble “handcrafted” CSS if all the rules that match a particular query be combined when the CSS is compiled.

:::scss
.profile-pic {
  @media screen and (max-width: 320px) {
    width: 100px;
    float: none;
  }
}

.biography {
  @media screen and (max-width: 320px) {
    font-size: 1.5em;
  }
}

It would be nice (and smaller) if that became:

:::css
@media screen and (max-width: 320px) {
  .profile-pic {
    width: 100px;
    float: none;
  }
  .biography {
    font-size: 1.5em;
  }
}

But instead we get:

:::css
@media screen and (max-width: 320px) {
  .profile-pic {
    width: 100px;
    float: none;
  }
}

@media screen and (max-width: 320px) {
  .biography {
    font-size: 1.5em;
  }
}

Nothing’s broken here, but it’s certainly not optimal. I think this would be a great issue to tackle, and it looks like there are some other smart optimisations they’re considering.

So go get it!

As before, you don’t have to work hard to get the new good stuff. Just run the following in your command line and you’re all set.

gem install sass --pre

A Standard Module Definition for Sass

2012-03-26T16:15:00-05:00

Since becoming a fan of Sass, one thing that has bothered me is that not much has been written about best practices for structuring Sass projects. This is one of a series of articles we will be writing to talk about some of the things that folks are doing to make their projects better.

In this article, I’d like to kickstart the discussion on developing a Standard Module Definition for Sass. I’ll start by sharing a couple of principles that I’ve found helpful for structuring Sass projects. (The principles here apply mostly to writing Sass for non-library code. We’ll talk more about some ideas for structuring library modules in a future article.)

1. A module is a unit of code contained in a partial

I like to define modules in Sass partials. Since Sass doesn’t currently have a way to namespace code, the easiest way to group code by function is to do so in a partial. One module per file. Example module names in typical projects might include: buttons, forms, lists, and typography.

2. Importing a module should never output code

I’m a strong believer in keeping your modules free of anything that would cause immediate CSS output. The idea is that you should be able to import any number of modules into your code-base and then make selective calls to control the output. This pretty much limits modules to mixins, functions, and variable definitions. (Sass 3.2 also introduces placeholder selectors which could also be used in a module definition.)

3. Each module should have a primary mixin

If appropriate, a primary mixin should be included in each module that outputs the standard usage of the module. This one is a little tricker to explain with words, so let me show you in code.

Here is an example _buttons.scss:

:::scss
// Primary mixin
@mixin buttons {
  a.button, button {
    @include button(black, silver);
    &.blue  { @include button(white, blue); }
    &.red   { @include button(white, red); }
    &.green { @include button(white, green); }
  }
}

// Button mixin
@mixin button($text-color, $bg-color) {
  font: 12px bold sans-serif;
  padding: 3px 8px;
  @include color-button($text-color, $bg-color));
  &:hover, &:focus { @include color-button($text-color, lighten($bg-color, 10%)); }
  &:active { background: darken($bg-color, 5%); }
}

// Color button mixin
@mixin color-button($text-color, $bg-color) {
  color: $text-color;
  border: 1px solid mix(black, $bg-color);
  @include background-image(
    linear-gradient(
      lighten($bg-color, 5%),
      darken($bg-color, 5%)
    )
  );
}

...

The idea here is that the buttons module includes all kinds of mixins for creating and styling buttons, but the primary mixin demonstrates and applies the default usage of the appropriate mixins. This makes it super simple to use the default behavior for a module in a stylesheet.

Here’s an example of how I often combine modules in my main stylesheet:

:::scss
.content {
  @include typography;
  @include buttons;
  @include lists;
  @include forms;
  ...
}

4. The name of the primary mixin should inherit the name of the module

I’d recommend that you try to pluralize your module names, where appropriate, and the name of your main mixin for that module should be the same as the name of the module itself. This simple naming convention will make it easy to import and use your modules without thinking hard about the names.

5. Variable definitions should always be defaulted

If a module defines top-level variables, they should always be defined with the !default directive. This will make it much easier to override those variables in a theme stylesheet or when reusing the module for other purposes.

Here’s an example of using the !default directive to declare defaults for variables within a module:

:::scss
$base-font-family: Helvetica, Arial, sans-serif !default;
$fixed-font-family: monospace !default;

6. Almost all project CSS should be written in modules

I like to code almost all of my CSS in modules using this pattern. This makes it much easier to reuse styles across stylesheets for a given project or even to share code between projects. It also helps me think about my code in a modular way from the very beginning – a discipline that I find quite helpful.

For me, modules have become the basic units or building blocks of my Sass projects. What practices do you find helpful for structuring your own projects?

Sass doesn't create bad code. Bad coders do.

2012-02-02T10:00:00-06:00

Those who don’t see any use for pre-processors such as Sass often use the “bad code” argumentation. It creates too specific selectors due to nesting, huge sprites and they hate the way Sass enforces an architectural approach that doesn’t work. And it’s all true. If you’re a poor developer. You know, one who would handcraft too specific selectors, 15MB sprites and doesn’t know how to cleanly structure a project.

Debunking the arguments against Sass

With this article I’ll try to debunk the arguments against using Sass that create fear, uncertainty and doubt. I believe these arguments to be in error and used by those who don’t have actual experience with pre-processors or have worked with people who didn’t “get it”. I’m sure I can convert any CSS out there to Sass, using substantially fewer characters, while maintaining the exact same output. Whatever Sass compiles to is up to you. Now, bring it on!

“Nesting leads to overly specific selectors”

Too much nesting sure does. There’s a pretty nifty solution for this: don’t do it. Mario has written an excellent article about the inception rule here on The Sass Way.

I understand it’s easy to fall prey to this; even 37signals does it. The basic rule is: don’t try to mimic your HTML structure in your Sass. It may seem handy at first, but in the end it will lead to completely non-reusable code due to the extreme specificity of selectors. You’ll end up copy/pasting chunks of Sass and cause code duplication. Keep your selectors shallow.

“Mixins will bloat your CSS by repeating code”

They may. When a mixin holds five lines of code, including it in your Sass ten times will lead to 50 lines of CSS. In most cases you don’t want that. My rule of thumb is: mixins without arguments smell. When the return value of your mixin is dependent on arguments you pass to it, it should generate different output with every use. For a mixin that returns the width based on a number of columns when using a grid based layout for instance, that makes complete sense.

For a lot of other uses, the @extend directive may be a better choice (as long as you read the next paragraph).

“The extend directive creates a lot of ugly selectors”

Ask yourself if your compiled CSS is meant to be human readable or machine readable. If you work in Sass, but know the resulting CSS will be hand edited, I would avoid extending selectors. When using @extend two times on a single selector, there will be code related to it at three places in the CSS (assuming you aren’t nesting extends).

For a browser however, the way the code is formatted doesn’t really matter, which is why minifying your code is a best practice. Pretty code is less important than performant code, and extending your selectors can definitely lead to DRY’er code than using mixins. On the other hand, don’t overdo it. If you find yourself extending your .clearfix class twenty times, you may consider adding it to your HTML (or learn how floats work). Use common sense.

“You can’t use Sass in an OOCSS (or any other architectural) approach”

Sure you can. If you want to use class names on every element in your HTML and define (extreme) shallow selectors in your CSS, Sass has got your back. If you want to take a nested approach, where you only set a class name on a wrapper element and use descendant selectors in your CSS, Sass is a good fit. You could even just take your handcrafted CSS, rename it to SCSS and only use those features in Sass and Compass that brighten up your day. Sass doesn’t have anything to do with your architectural approach. Tell it what to do, and it will do it.

Know your compiler

You don’t need to know the internals of Sass to know what will be done to your code. Just open the processed CSS once in a while and see what it looks like. It isn’t rocket science to learn to predict what your Sass code will be compiled too. It’s a good thing to think “how would I do this in plain ol’ CSS” when writing Sass. At least you’ll know if a certain use of @extend adds a gazillion selectors to your CSS and make an informed decision as to use it or not.

Sass is just a tool

Just as you can’t expect everyone who holds a hammer to be a master carpenter, Sass doesn’t automagically turn you into a great front-end developer. In the end, Sass is “just” a powerful tool. And when taking responsibility in this great power, it will help you write and maintain your stylesheets the easy way, whatever approach you to take. Know what you’re doing and you’ll be fine.

Zurb Foundation, for Sass and Compass

2011-12-22T14:30:00-06:00

What do you get when combine the power of Sass with Zurb? You get Zurb Foundation for Sass and Compass.

Foundation is awesome.

I come out of the gate saying, “Foundation is awesome.” It’s the perfect flexible grid from desktop to mobile.

Foundation includes forms, buttons, and a UI library. Plus other ZURB Playground favorites like Orbit and Reveal.

With case studies like ZURB Jobs, Swizzle and the Foundation site itself, how can we deny ZURB of hitting this one out of the park?

Foundation’s Features

ZURB Foundation features a set of global styles that include Eric Meyer’s reset, tested styles for typography, links, lists, tables and more.

The Grid, built for rapid prototyping and mobility
Various layout options
UI Elements
Buttons and forms
Plus playground favorites Orbit and Reveal

And ZURB didn’t stop there, they did an awesome job showing off the documentation too. You can learn about all the features of Foundation, as well as how to use it on mobile and desktop displays.

Installation

From your Terminal …

:::bash
(sudo) gem install ZURB-foundation

If you use Bundler, simply add ZURB-foundation to your Gemfile and bundle install.

:::bash
gem 'ZURB-foundation'

Form here, you have a few options on getting started with ZURB Foundation. You can start a Compass-based project with ZURB Foundation or you can install ZURB Foundation into an existing Compass-based project.

Start a Compass-based project with ZURB Foundation

You can start a brand new project using Compass and ZURB Foundation with the following compass command.

:::bash
compass create <project-name> -r ZURB-foundation --using ZURB-foundation --force

If you’d like to require ZURB Foundation to install using a particular Sass syntax, use the Compass --syntax flag. Here’s an example.

:::bash
compass create <my_project> -r ZURB-foundation --using ZURB-foundation --syntax sass --force

Install ZURB Foundation into an existing Compass-based project

You can install ZURB Foundation into an existing project with Compass in place already.

:::bash
compass install ZURB-foundation/project

Running this will unfurl a number of files from the ZURB Foundation gem using the Compass framework.

:::bash
-> % compass install ZURB-foundation/project
directory images/misc/ 
directory images/orbit/ 
directory javascripts/ 
directory sass/ 
directory stylesheets/ 
   create sass/app.scss 
   create sass/ie.scss 
   create javascripts/app.js 
   create javascripts/forms.jquery.js 
   create javascripts/jquery.customforms.js 
   create javascripts/jquery.min.js 
   create javascripts/jquery.reveal.js 
   create javascripts/jquery.orbit-1.3.0.js 
   create javascripts/jquery.placeholder.min.js 
   create index.html 
   create humans.txt 
   create robots.txt 
   create MIT-LICENSE.txt 
   create images/misc/button-gloss.png 
   create images/misc/button-overlay.png 
   create images/misc/custom-form-sprites.png 
   create images/misc/input-bg.png 
   create images/misc/modal-gloss.png 
   create images/misc/table-sorter.png 
   create images/orbit/bullets.jpg 
   create images/orbit/left-arrow.png 
   create images/orbit/loading.gif 
   create images/orbit/mask-black.png 
   create images/orbit/pause-black.png 
   create images/orbit/right-arrow.png 
   create images/orbit/rotator-black.png 
   create images/orbit/timer-black.png 
   create stylesheets/app.css 
   create stylesheets/ie.css

Awesome examples to check out

Responsive Web Design in Sass Part 2: Media Queries in Sass

2011-12-02T17:00:00-06:00

EDITOR'S NOTE

Mason followed up this article with Responsive Web Design in Sass: Using Media Queries in Sass 3.2

In part one we talked about how Sass can help with fluid layouts and images. Now we’ll turn our attention to the new kid in town. Media queries are the tool that takes a design from fluid to truly responsive.

I Resisted Fluid Layouts (too)

Fluid or elastic layouts allow your site’s content to grow and shrink to fit the screen, so that solves the problem right? OK. See you later.

I didn’t think so either. As much as I wanted to, I just couldn’t get on board with all the rage of fluid and elastic layouts. Personally, I resisted them for for one primary reason.

Not all layouts work at all sizes.

When a layout of mine grew or shrank outside the “sweet spot” of my design I felt that it usually ruined the balance and composition of the design. At least when I made a fixed layout I could place the burden of having a big enough screen on the user.

It’s clear to me now that with the explosion of newly connected devices, placing the burden of having the right size screen on the user is no longer a suitable solution. It’s a recipe for failure.

:::html
<q class="smug-designer">
  "It wasn't <em>my</em> fault they were on a netbook.
  I'm concerned with "mainstream" (desktop) users."
</q>

But, I knew designing to a fixed layout was a cheat and I hated horizontal scroll bars as much as my users and clients did. I just didn’t know of a way to do fluid layouts without compromising my design.

And then, my jaw dropped along with all the other web nerds when I read Ethan Marcotte’s article on A List Apart. All hail media queries!

What are media queries and why should I care?

If you’ve ever created a print style sheet you’ve used media-specific CSS. In that case you called a separate CSS file just for print by setting the media attribute of a link:

:::html
<link rel="stylesheet" href="paper.css" media="print" />

This gave us some control over media types, but that’s it. Then CSS3 introduced the concept of using a query in that space as well. You can add your query in the <link> tag, or join the cool kids and use the @media rule in CSS. More on that later.

First let’s look at what kind of queries we can write. If you look at the W3C Spec you’ll see a dazzling array of different properties you can check. The ones I’m most interested in are the ones concerning width, height, orientation, and ratio. By swapping out different rules based on these properties you can change the size and shape of your design to truly fit the viewing area.

Here’s a simple query in the <link> tag that will load a css file for small screens.

:::html
<link rel="stylesheet" media="screen and (max-width: 480px)" href="small.css" />

This is great, but if we want to manage a lot of different options these files can add up quickly. Fortunately we have the @media rule. You can use these inside any CSS file to apply specific rules only when the query expression is true.

Here I’m setting the font-size of an <h1> to be larger on a large screen.

:::scss
// set a variable for the font size
$h1-size: 36px

h1 {
  font-size: $h1-size;
}

// this will only affect wide screens
@media screen and (min-width: 1024px) {
  h1 {
    font-size: $h1-size * 1.5;
  }
}

Which compiles to:

:::css
h1 {
  font-size: 36px;
}
@media screen and (min-width: 1024px) {
  h1 {
    font-size: 54px;
  }
}

You can use these in Sass just fine, and inside a query you can use all the Sass features you like. In the above example I used and manipulated a variable. You should note, however, that you can’t use variables in the query declaration itself. It would be nice to write the following, but it won’t work.

:::scss
$breakpoint: 1024px;

@media screen and (min-width: $breakpoint) {
  content: "this won't work :(";
}

Skip ahead to see how the upcoming Sass 3.2 release will help with this.

@media Bubbling

Sass does provide what I consider to be a pretty killer feature for authoring @media when you nest them inside other selectors. If you add a @media query by nesting it inside a selector Sass will “bubble” that @media query and the new rule outside of the nest and back out to the root of your style sheet.

I use @media un-nested (as mentioned above) when I’m setting up large-scale changes like a responsive master grid, but I find that I need to make small adjustments much more often. For example, lets say you have a profile picture that looks great large and floated to the left on a desktop, but needs to shrink on a smaller screen. It also needs to stop floating on a really wide screen.

In Sass we can write that like this.

:::scss
.profile-pic {
  float: left;
  width: 250px;
  @media screen and (max-width: 320px) {
    width: 100px;
  }
  @media screen and (min-width: 1200px) {
    float: none;
  }
}

Sass will see this and know that you want to apply that query to the selector it’s nested in. It compiles to CSS like so:

:::css
.profile-pic {
  float: left;
  width: 250px;
}
@media screen and (max-width: 320px) {
  .profile-pic {
    width: 100px;
  }
}
@media screen and (min-width: 1200px) {
  .profile-pic {
    float: none;
  }
}

I really like how this lets me keep my rules for the different options adjacent to both the original rule and to each other. It really speeds up the process, especially when you turn to the details of your responsive project.

When I was designing the homepage for The Coding Designer’s Survival Kit I made a module where the elements laid out in a circle that took up a lot of space in the wide screen version of the design. However in any width lower than 900px they overflowed the boundary and the circle no longer made sense. In this case the best design decision was to lay those elements out in another way, and I chose a grid. If you’re curious you can view my source sass for that project.

The Future of Media Queries in Sass

EDITOR'S NOTE

Mason followed up this article with Responsive Web Design in Sass: Using Media Queries in Sass 3.2

Sass 3.2 is about to make all this calculating absolutely trivial. At the moment, Sass 3.2 is only available as an Alpha release. There’s a milestone on Sass’s GitHub project as well that’s at the 33% mark.

In my examples above you may have noticed that all the media queries were written out and included the pixel value for each break point, in every media query I used. “What? Where are the variables?”, you asked? Well it turns out that until 3.2, which is yet to be released, Sass didn’t support variables in media queries. Well, strictly speaking it still doesn’t. But, Sass 3.2 introduces the ability to pass content blocks to functions. Chris Eppstein published a gist showing how you might use this. I’ll use these new mixins to redo my profile picture example:

:::scss
@mixin respond-to($media) {
  @if $media == handhelds {
    @media only screen and (max-width: 320px) { @content; }
  }
  @else if $media == medium-screens {
    @media only screen and (min-width: 321px) and (max-width: 1024px) { @content; }
  }
  @else if $media == wide-screens {
    @media only screen and (min-width: 1024px) { @content; }
  }
}

.profile-pic {
  float: left;
  width: 250px;
  @include respond-to(handhelds) { width: 100% ;}
  @include respond-to(medium-screens) { width: 125px; }
  @include respond-to(wide-screens) { float: none; }
}

And the compiled css:

:::css
.profile-pic {
  float: left;
  width: 250px;
}
@media only screen and (max-width: 320px) {
  .profile-pic {
    width: 100%;
  }
}
@media only screen and (min-width: 321px) and (max-width: 1024px) {
  .profile-pic {
    width: 125px;
  }
}
@media only screen and (min-width: 1024px) {
  .profile-pic {
    float: none;
  }
}

This makes it possible to set up a mixin for all your @media breakpoints and reuse that as often as you need. This makes it incredibly easy to keep track of all the different ways your styles may fracture as you do specific styling in each breakpoint. I have to say it got me salivating. I can tell you are too. Once that feature is in place we should be able to create some very smart mixins and templates for media queries (and other tricks too!) and responsive grid frameworks.

Sass 3.2 Alpha

You can try out the new Sass 3.2 features I’ve talked about in this article before its official release by installing it with this command:

gem install sass --pre

Or, if you use Bundler, simply add this to your Gemfile and bundle install.

gem "sass", "~> 3.2.0.alpha.35"

Interactive Sass: Having Fun On The Terminal

2011-11-22T09:30:00-06:00

Most people who use Sass are familiar to some degree with the command line. While programs like Compass.app and Scout.app are making it easier to use Sass and Compass without using the command line, hidden gems await those who are willing to do so.

The Interactive Sass Interpreter

One of these little gems is the interactive Sass interpreter. Many modern programming languages (like Python and Ruby) ship with an interactive version that can be used from the command prompt. These programs read a line of code in from the user, evaluate it, and output the result. It’s called a Read-Eval-Print loop, also known as REPL.

To use the interactive interpreter for Sass, open up the command prompt and type:

:::bash
sass --interactive

Or, if you like, use the short version of the same command:

:::bash
sass -i

Once started in interactive mode, the sass command will output a prompt ”»” asking for input. Enter any valid Sass Script expression and it will output the result on the line below:

>> 12 * 4 - 6
42
>> 1px + 1px + 1px
3px
>> lighten(#333, 10%)
#4d4d4d

Sass Script is a small subset of the Sass language. It mostly includes the mathematical parts of Sass and functions. You can’t use Sass features like mixins or variables. But even with this small amount of functionality, you can still use interactive Sass to learn some interesting things about the Sass language. For instance:

>> 1em + 1px
SyntaxError: Incompatible units: 'em' and 'px'

Oh! That should have been obvious. Sass has no way of adding ems and pixels. So it will throw an error if you try to add them.

And this one:

>> #333 + #666
#999999

Wow! Did you know that you can add colors in Sass? And that’s not all, you can also subtract, multiply and divide!

>> #999 - #333
#666666
>> #333 * #030303
#999999
>> #999 / #030303
#333333

Now I don’t use color math with Sass every day, mostly because Sass color functions have replaced the need for it, but you can get an idea of how they work using interactive Sass.

Speaking of Sass color functions, I often use interactive Sass to reduce a series of complex color functions to a color value:

>> saturate(#113, 10%)
#0e0e36
>> adjust-hue(green, 10deg)
#008015
>> adjust-color(blue, $lightness: -20%, $hue: 20deg)
#330099

This allows me to design in the browser tweaking color values with functions. When I arrive at a color I like, I can simplify it to it’s actual color value using the sass command in interactive mode.

To quit once you’ve entered interactive mode, just type Ctrl+D.

Conclusion

As you can see, the interactive Sass interpreter is an nice way to play with many Sass Script functions, math, color functions and more. If you’re a Compass user (as you should be), it’s also worth mentioning Compass includes it’s own version of interactive Sass which will give you access to an array of additional functions that Compass provides. Just execute compass interactive on the command prompt.

How Sass Can Shape The Future of CSS

2011-11-20T20:00:00-06:00

The rise in popularity of CSS extensions, such as Sass, in recent years has not gone unnoticed by the people who work on proposing and standardizing modules for CSS3 (and CSS4).

Sass Features Being Adapted for Submission

Many of the key features found in Sass are being adapted for submission to the W3C. Variables, Mixins, and Nesting are all mooted for inclusion in CSS, and we may see some of them appear in the near future.

Then again, we may not; resistance to the proposals is quite strong from certain members - for example, Bert Bos wrote a long article on why he considers CSS Variables to be harmful. But I thought it would be interesting for the Sass community to see how the software to which you develop and contribute to (Sass) is being used to discuss the future of the web.

The Variables Proposal

This proposal should look very familiar to you - it’s the same syntax that Sass uses, with one addition. Each variable is defined using a three-part syntax: first you set up the declaration using the @var at-rule, then you provide a unique name with the $ character before it, then you set the value:

:::css
@var $foo #F00;

Once set up like this, you can reference your variable by using the unique name as a value:

:::css
h1 { color: $foo; }

This proposal has already been put forward to the W3C, and I’ll tell you the result of that shortly.

The Mixins Proposal

As with Variables, you should be very familiar with the Mixins proposal - the syntax used in Sass was the inspiration. You create a declaration block using the @mixin at-rule, assign a unique id, and then add your rules:

:::scss
@mixin foo { color: #F00; font-weight: bold; }

When you need to use that code block you call it using the @mix directive and the unique id you previously assigned:

:::css
h1 { font-size: 2em; @mix foo; }

As you can see, the only difference is that the CSS proposal uses @mix in place of Sass’s @include. As with Sass, you can also use parameters with Mixins:

:::css
@mixin foo($bar #F00) {
  border-color: $bar;
  color: $bar;
}
h1 {
  @mix foo(#00F);
}

An Alternative Variables Syntax

Recently, an alternative syntax for Variables has been proposed. This syntax looks and acts somewhat similarly to the HTML data attribute, although it’s not the same. In this proposal variables are scoped to elements (for global scope, you’d use the :root selector) and the variable name is prefixed with data-:

:::css
:root {
  data-foo: #F00;
}

Then you reference the variable by using the unique name in the data function:

:::css
h1 {
  color: data(foo);
}

This has the advantage of allowing scoped variables, and integrating better with the CSSOM, JavaScript, as well as inspector tools like Firebug or Dragonfly.

It must be stressed, however, that this is still only at the discussion stage.

So When Will We See Them?

As I said, maybe never. As I understand it, the first Variables proposal was not well received by the W3C - but the module author, Tab Atkins, is continuing to refine it anyway. Tab is also key to the creation of the alternative syntax. You can follow along with Tab and his writing at his personal blog where he shares his thoughts on web standards as well as details surrounding discussions on the future of CSS.

As for Mixins, they were rejected out of hand and probably won’t be pursued. The reason given? Lack of use cases. But I can’t imagine that you, as Sass creators, developers and users are short of use cases for Mixins. So, if you have them I’d love to read them - please leave a comment below sharing your thoughts if that’s the case.

If work does continue on these proposals, or any part of them, I think that it would be a matter of little time before browsers started to implement them; I believe, in fact, that WebKit already implemented Variables, only to remove them after feedback from the W3C.

Conclusion

I have to confess that I’ve only briefly experimented with Sass, and have not used it in any production websites, but what I like about it is the ease with which it’s been possible to adapt the syntax into CSS itself. It’s great to see community-created language extensions influence the evolution of the web, and even if none of these proposals ever make it to the implementation stage, you can be sure that at the very least they form part of the standards conversation.

Nested Selectors: The Inception Rule

2011-11-20T10:30:00-06:00

It’s well known that Sass is an efficient, realiable and precise tool which gives us great power and freedom to make CSS fun and less of a pain to author; however with great power comes responsibility.

The Problem

We’ve all been there, in the CSS realm, where all code lives at a “root level” and writing nested selectors means writing a lot of code for each CSS declaration.

Today we’re going to dive into the most basic rule in the Sass universe. It’s called, “The Inception Rule.” This rule will help you survive the most common mistake that many Sass developers, beginners and advanced make.

Take this code for example:

:::css
.post {
  border-radius: 3px;
  background: #FFF8FF;
  border: 1px solid #EFC6F3;
  padding: 15px;
  color: #333333;
}
.post .title, .post .alt-title  {
  color: #000000;
  font-size:20px;
}
.post .alt-title {
  border-bottom:1px solid #EFC6F3;
}

Odds are that while you were stuck in the CSS realm you began taking the approach of making loads of classes and then stuffing them in your HTML like no tomorrow. Have you ever added 5 classes to a single DOM element?

:::html
<div class="post complete highlight rounded clearfix">...</div>

That was the everyday bread and butter. We all thought we wouldn’t be able to enjoy writing CSS. However, as soon as Sass appeared in your life, you discovered this was the way to go when working with CSS.

And just as easy as it is to get going with Sass, it’s also easy to use it incorrectly.

When you begin working with Sass, the first feature you fall in love with is “nested selectors”. Being able to nest selectors under another is a wonderful feature which saves keystrokes and possibly Carpal Tunnel Syndrome as well.

Let’s look at an example of nesting selectors in Sass.

:::scss
$border: 1px solid #EFC6F3;
.post {
  border-radius: 3px;
  background: #FFF8FF;
  border: 1px solid $border;
  padding: 15px;
  color: #333333;
  .title {
    color: #000000;
    font-size:20px;
  }
  .alt-title {
    @extend .title;
    border-bottom:1px solid $border;
  }
}

The above code will output the exact same code as the code you didn’t like to write when you were writing CSS because of all repetition.

Here’s the output of the above Sass just so you can see how this translates to CSS.

:::css
.post {
  border-radius: 3px;
  background: #FFF8FF;
  border: 1px solid 1px solid #efc6f3;
  padding: 15px;
  color: #333333;
}
.post .title, .post .alt-title {
  color: #000000;
  font-size: 20px;
}
.post .alt-title {
  border-bottom: 1px solid 1px solid #efc6f3;
}

And so, like a child with a new toy, we begin to use this feature in -what we think- is its “max potential”. But actually what’s taking happening is some may call, a “CSS Selector Nightmare.”

CSS Selector Nightmare

The so called nightmare between front-end engineers is when the styles are bloated and tightly coupled to the DOM to a point where modifying anything about the structure ends up breaking the front-end.

Let’s look at this not-so-pretty piece of HTML.

:::html
<body>
  <div class="container">
    <div class="content">
      <div class="articles">
        <div class="post">
          <div class="title">
            <h1><a href="#">Hello World</a>
          </div>
          <div class="content">
            <p></p>
            <ul>
              <li>...</li>
            </ul>
          </div>
          <div class="author">
            <a href="#" class="display"><img src="..." /></a>
            <h4><a href="#">...</a></h4>
            <p>
              <a href="#">...</a>
              <ul>
                <li>...</li>
              </ul>
            </p>
          </div>
        </div>
      </div>

    </div>
  </div>
</body>

Because Sass offers you the ability to nest your selectors, and you know that having your code encapsulated is the “good way to avoid collisions with other styles”, you might find yourself mimicking the DOM in your Sass (bad idea).

Let’s look at some Sass you might craft for our not-so-pretty piece of HTML.

:::scss
body {
  div.container {
    div.content {
      div.articles {
        & > div.post {
          div.title {
            h1 {
              a {
              }
            }
          }
          div.content {
            p { ... }
            ul {
              li { ... }
            }
          }
          div.author {
            a.display {
              img { ... }
            }
            h4 {
              a { ... }
            }
            p {
              a { ... }
            }
            ul {
              li { ... }
            }
          }
        }
      }
    }
  }
}

This is “all good”, right? Using the above code, you can predict 100% of the time what’s going to happen with your stylesheet. There is no cascading that can beat the specificity …

After compiling the Sass, we take a look at the result on to find that we’ve created a CSS monster. Ugh!

:::css
body { ... }
body div.content div.container { ... }
body div.content div.container div.articles { ... }
body div.content div.container div.articles > div.post { ... }
body div.content div.container div.articles > div.post div.title { ... }
body div.content div.container div.articles > div.post div.title h1 { ... }
body div.content div.container div.articles > div.post div.title h1 a { ... }
body div.content div.container div.articles > div.post div.content { ... }
body div.content div.container div.articles > div.post div.content p { ... }
body div.content div.container div.articles > div.post div.content ul { ... }
body div.content div.container div.articles > div.post div.content ul li { ... }
body div.content div.container div.articles > div.post div.author { ... }
body div.content div.container div.articles > div.post div.author a.display { ... }
body div.content div.container div.articles > div.post div.author a.display img { ... }
body div.content div.container div.articles > div.post div.author h4 { ... }
body div.content div.container div.articles > div.post div.author h4 a { ... }
body div.content div.container div.articles > div.post div.author p { ... }
body div.content div.container div.articles > div.post div.author p a { ... }
body div.content div.container div.articles > div.post div.author ul { ... }
body div.content div.container div.articles > div.post div.author ul li { ... }

There are so many reasons why this is just plain wrong, from rendering performance to file-size performance. Just think about how many bytes this will add to your CSS. But, the odds are you may say:

“Hey, computers are faster now! and also the internet download speeds are better!” - User who hates Front-End Engineering.

But that’s not the only problem! Since your styles are so specific to the DOM, maintainability is now a problem.

Any change you make to your markup will need to be reflected into your Sass and vice versa. It also means that the styles are bounded for life to the those elements and that HTML structure which completely defeats the purpose of the “Cascade” part of “Cascading Style Sheets.”

If you follow this path, you might as well go back to writing your CSS inline in your HTML (please don’t).

Meet The Inception Rule

To prevent you from falling into this nightmare, I created a simple rule. Until now, this rule has remained unwritten, but many followed.

The Inception Rule: don’t go more than four levels deep.

This basically means that you shouldn’t be too specific or mimicking the DOM at any point. If you find yourself more than four levels deep, that’s a red flag. Of course there are times when you’ll be forced to go there, but it’s not something you should be doing too much.

Making it fit in the Four or Less principle.

Once you understand the problem behind being too specific with selectors, you need to understand how to make your code more general by improving your understanding of contexts, objects and interaction states.

Site Context

If you’re styling something that lacks completely of classes or ids, then odds are you’re going to need at most just one level. Good examples of this would be the default styling of h1 - h6, ul, p.

There may be cases where it makes sense to add several selectors such as a CSS reset. Please, use common sense when crafting site context styles.

Page Context (layouts, sidebar widths, heights)

If you’re styling the layout (sidebar and content dimensions, elements that vary depending on the page) then you’re talking about page context. Usually you’ll need at least two levels of indentation to achieve this. However, remember that you should only assign styles things that change on a page basis, not the objects themselves. I’ll cover objects in the next section.

Here’s an example of what I mean.

:::scss
.cart {
  #sidebar { width: 150px; }
  #content { width: 850px; }
}

Objects

An object is an element, alone or with children, that is identified by a class or an id. Usually, this is going to be the most common type of styling you should have in your code. Objects can be anything that should be delivered to the view as a whole. You can use objects as basic styling and then modify them using “page context” styles when needed.

Here’s a list of elements commonly styled as objects.

:::text
#sideabr
#content
#footer
.blog-post
.comment
.widget
.logo
.user
.button

You’ll usually set one top class to identify the object and set that as a base for the selector, from there you should style using the most general selector available.

:::scss
ul.special-deal {
  ...
  li {...}
  a {...}
}

Note that objects should have at most 4 levels. Most of the time you’ll stay around the 2-3 level range, and the fourth would be the interaction state.

Interaction State

The interaction state covers anything that changes when you interact with an object. You’ll usually get close to the fourth indentation limit when adding interaction states. This is expected and is acceptable.

Remember

Be smart: Think about how the compiler will build your code and ask yourself if the code it’s generating is really needed in your CSS. I always ask myself, can this style be achieved with less selectors?

Be crafty: Use everything the compiler provides to you. For example, using the @extend directive or a mixin. Each has it’s own implications on the output.

Be expressive: If you are adding a declaration that affects global html tags, document it with comments. Commenting your code can be huge when coming back to code weeks or months later. Comments are your friend. If you’re nesting article aside section or h3, you better have a good reason!

Be creative: Is there a way to make the HTML code easier to work with CSS without adding extra classes? If there is and it doesn’t affect semantics. Do it. Examples of what I mean could be using adjacent selectors, targeting direct child elements and so forth. Get to know the rules of CSS before just nesting your Sass to the nth degree.

Be moderate: Abusing anything is bad. Use your common sense when in doubt.

The Sass Way

Avoid nested selectors for more modular CSS

Contextual selectors

A more modular way

Clashing worlds

Context and modularity

Conclusion

How to structure a Sass project

Basic directory structure

Primary stylesheet

Modules, partials, and vendor

Using a base partial

One step further

Further exploration

Responsive Web Design in Sass: Using Media Queries in Sass 3.2

Variables in queries

Variables as full query

Variables on either side of the colon in a query

Variables in queries, using @content

Nothing is Perfect

@extend within @media

Combining @media Queries on Compile

So go get it!

A Standard Module Definition for Sass

1. A module is a unit of code contained in a partial

2. Importing a module should never output code

3. Each module should have a primary mixin

4. The name of the primary mixin should inherit the name of the module

5. Variable definitions should always be defaulted

6. Almost all project CSS should be written in modules

Sass doesn't create bad code. Bad coders do.

Debunking the arguments against Sass

“Nesting leads to overly specific selectors”

“Mixins will bloat your CSS by repeating code”

“The extend directive creates a lot of ugly selectors”

“You can’t use Sass in an OOCSS (or any other architectural) approach”

Know your compiler

Sass is just a tool

Zurb Foundation, for Sass and Compass

Foundation is awesome.

Foundation’s Features

Installation

Start a Compass-based project with ZURB Foundation

Install ZURB Foundation into an existing Compass-based project

Awesome examples to check out

Links

Responsive Web Design in Sass Part 2: Media Queries in Sass

EDITOR'S NOTE

I Resisted Fluid Layouts (too)

What are media queries and why should I care?

@media Bubbling

The Future of Media Queries in Sass

EDITOR'S NOTE

Sass 3.2 Alpha

Interactive Sass: Having Fun On The Terminal

The Interactive Sass Interpreter

Conclusion

How Sass Can Shape The Future of CSS

Sass Features Being Adapted for Submission

The Variables Proposal

The Mixins Proposal

An Alternative Variables Syntax

So When Will We See Them?

Conclusion

Links

Nested Selectors: The Inception Rule

The Problem

CSS Selector Nightmare

Meet The Inception Rule

Making it fit in the Four or Less principle.

Site Context

Page Context (layouts, sidebar widths, heights)

Objects

Interaction State

Remember