When we released Neat—a semantic grid framework built on top of Sass and Bourbon—earlier this fall, it was welcomed with great enthusiasm in the Sass community. Today I’m pleased to announce that Neat is finally out of the beta, introducing new responsive features, a visual grid, and better support for non-Rails projects.
The breakpoint() mixin becomes media() in Neat 1.0 in order to keep the syntax as close to CSS3 as possible.The update also introduces new-breakpoint(), a helper function that you can use to define new media contexts and use them throughout your project.
A media context is comprised of a width breakpoint and an optional total column count that would redefine the grid. For instance, using a four-column grid for mobile devices would involve defining a new media context with a max-width of 480px and a grid column count of 4, like so:
$mobile: new-breakpoint(max-width 480px 4);
Once defined, you can use the $mobile context throughout your project using the media() mixin:
div {
height: 500px;
@include media($mobile) {
// All layout mixins in this context will use a base grid of 4 columns
height: 100px;
}
}
Which would output the following CSS:
div {
height: 500px;
}
@media screen and (max-width: 480px) {
div {
height: 100px;
}
}
Additionally, you can now use both min-width and max-width in the same context:
$tablet: new-breakpoint(min-width 481px max-width 991px 8); // Use an 8 column grid on tablets
Keep in mind that each call of the media() mixin would result in a separate @media block in the CSS output, a Sass limitation that is still being actively discussed.
Due to popular demand, we’ve baked in a pure-Sass visual grid in this milestone release. You can now display the underlying grid either as a background or as an overlay, and even change its color and opacity to better fit your content. Add the following line in your Neat settings to turn the visual grid on:
$visual-grid: true;
You can then change its look by overriding the default variables:
$visual-grid-color: yellow;
$visual-grid-index: front;
$visual-grid-opacity: 0.3;

Bonus: If you use new-breakpoint() to change the base grid, the visual grid will automatically follow. You’re welcome.
If you are planning to use Neat on a non-Rails project, you’re in for some good news. Neat 1.0 comes with a command line interface that allows you to install, update and remove the framework without hassle.
Start off by installing the gem in your Ruby environment:
gem install neat
Then run the neat install command in your project Sass folder:
cd your-project/your-sass-folder
neat install
To update Neat:
gem update neat
cd your-project/your-sass-folder
neat update
Make sure you don’t alter any internal Neat files as any changes would be overridden when you run this command. Lastly, you can remove Neat either by deleting the folder or by running neat remove.
This update also comes with a few bug fixes, namely the compatibility between nested columns and the shift() mixin, and a new _neat-helpers.scss file that you can use to access helper functions without having to import the whole framework.
The only thing we’re missing at this point is your feedback, so give Neat a spin and let us know what you think through comments, tweets and pull requests.
While redesigning the thoughtbot site, I gave myself a challenge: create an easily editable and maintainable baseline grid. I figured that there had to be an easier way to do this with Sass than with plain old CSS.
I started off going to the wonderful modulargrid.org to create my grid. I grabbed the png and threw it into the background so I could be certain everything is aligning perfectly. Then I created 3 variables based on the grid; one for the column unit width, the gutter width and line-height. This made things conceptually easier for me instead of trying to balance numbers.
$line-height: 20px; /*line-height for the site*/
$unit: 60px; /*column size*/
$gutter: 25px; /*gutter size*/
Almost as soon as I had started, Sass 3.1 came out touting functions and in the change log examples I found this gem:
@function grid-width($n) {
@return $n * $unit + ($n - 1) * $gutter;
}
This function calculates that width of the column by giving it the number of units you want it to span. Now all I needed to do is drop in grid-width() for any width and it will conform to the column sizes in my grid. For example, I wanted the grid to be 12 units wide, so on the wrapper for the site I put:
width: grid-width(12);
Of course this isn’t always perfect, the box model adds padding and the border to the width of the box and it breaks the grid. Bah. But Sass is wonderful and can do simple math and can apply that even to functions. So on a box that spans 4 columns but has 20px of padding on both sides I can subtract the padding to get the correct width of the column.
padding: 20px;
width: grid-width(4)-(20px*2);
The background image that I had for the grid also gave me guidelines for where the baseline should fall. Then all vertical spacing for the design uses the line-height variable. Everything from padding to the margin to the height of the images can all be declared with the line-height variable and some multiplication.
height: $line-height*6;line-height
margin-top: $*3;line-height
padding: $;
Again, I ran into scenarios with the box model where I didn’t want to use the whole line-height. These changes and exceptions were easy to accommodate with a little math just like the grid-width().
padding: ($line-height*2)-(1) 0; /*Account for 1px border*/
Throughout all the Sass I’ve successfully avoided doing any real calculations and feed Sass a bunch of math problems. Updating and maintaining the layout is easy, anyone who goes into the Sass won’t have to figure out what the width of a 3 columns would be. It also has the ability to be easily adaptable to having a fluid layout.
The grid-width function has also been incorporated into Bourbon, our default set of mix-ins and functions. Use variables $gw-column and $gw-gutter and then you are all set. No need to set up the function.
If you’d like to get some more Sass and advanced HTML & CSS tricks come to my workshop on Sept. 26th & 27th.
After our first Design for Developers workshop in December, we shared a few examples of student work we especially liked.
The next Design for Developers workshop is just a few weeks away, and I thought it would be interesting to highlight some common problems our first group of students had while working on their projects, specifically around grids.
We asked all students to use the 12 column, 960 grid when designing their pages in order to focus their work. However, it was very common for students to build unnecessarily complex grids instead of taking advantage of the simplicity that the 960 grid offers. Let’s look at four examples of problematic grids, along with strategies for improving them. As you’ll see, the solutions are straightforward: make it simpler!
The first two examples have a similar problem: they are confused about whether they want to be a 3 or 4 column layout.

In the first example, the three columns on the left group together nicely. But the column on the right doesn’t feel coherent with the rest of the layout.

My solution? Stick with a uniform 3 column grid. The wider, more regular columns create a better rhythm across the page, and also give you more room to work with. The student who built this page was using the small column on the right for a navigation list. But it would be better to move that elsewhere on the page, and let the content on the left fill the width of the page. Often times using the grid correctly means re-thinking the placement of elements on the page.

The second example is similar, but has even more problems. The three columns on the right stray from the grid in an attempt to fit themselves into a space that is probably too narrow. The contrast with the correctly sized column on the left is awkward.

In this case, a uniform 3 column grid would also work, as would a uniform 4 column grid. Because a 12 column grid system can be equally divided by both 3 and 4, these column sizes are the most reliable choices when working with the 12 column 960 grid. They will create equal divisions of the page that are wide enough to fit most content, and as we’ll see below, they look good when matched with each other on the same page.
The next two examples suffer from awkward mixing of column groups.

The first example starts with the right approach, using three equally sized columns through the center of the layout. The problem comes with the columns above and below. When mixing columns with different widths, the goal should be a harmony between all elements on the page. Unfortunately, in this example the columns clash with each other.

The solution is to use column groups that have a more harmonious relationship to each other. We achieve this by matching the 3 column group in the center with a 4 column group below it, and letting the header run the full width of the page. As we said above, 3 and 4 column groupings are often the best choice when working with the 960 grid. The intervals are more regular and we reduce the clash of irregular columns.

In our final example, the middle group of columns is again well defined, but the columns at the top and bottom again clash. The one unit of white space at the top of the page is especially troublesome, as it stops the eye and disrupts the flow of the page.

Again, the solution is to use a simpler, more consistent approach to the column groups. We want the columns to sit next to each other comfortably, and the lead the eye down the page naturally.
There are of course other solutions to the problems I’ve highlighted. But the best approach is often to remove any complex grid structure in favor of groupings of 3 or 4 columns.
If you browse through the example sites on the official 960 grid site you’ll notice that many of them are using a simple 3 or 4 column layout. A straightforward approach to the structure of your page doesn’t have to limit your design. Instead, it provides a solid base that will introduce clarity to your layout. And that’s always beautiful.
We encourage developers who are looking to learn more about grid systems and other fundamentals of visual design to sign up for our next Design for Developers workshop, taking place Feb 21 through 23 at our Boston office.