Responsive Grids With Susy

Responsive Grids With Susy

Tutorial Details
    • Language: SCSS
    • Library: Susy
    • Framework: Compass
    • Estimated Completion Time: 30 Minutes

Are you happy with with any of the CSS grid libraries available? No? I don’t blame you. Enter Susy, a plugin for the Compass CSS framework that lets you create your own custom grid framework, minimizing overhead, while making it more understandable to use. Sounds good, right? Let’s jump right in.

I’m not going to delve much into Compass or SCSS (the language you write the CSS in), but feel free to refer to our Maintainable CSS With Sass and Compass Premium course, if you want to learn about them.


Setting the Stage

You can create three different types of grids: static, fluid and magic.

Today’s popular grid libraries seem to fall short in one way or another. Grids like 960 and Blueprint are both static grids with very specific pixel values. Viewing these grids on screens that are under 950 pixels wide results in horizontal scroll bars–the bane of the Web.

Fluid grids are tricky to get right, but a few do exist. Most fluid grids work with percentages instead of pixels, but they tend to have a maximum size and make it impossible to scale past a respectable maximum width. By itself, a fluid layout is almost as bad as a fixed layout, because while you get better coverage of desktop computers, mobile devices tend to suffer with a worse layout. In this particular situation, a static grid gives you a better experience. Yes, you do have to scroll horizontally on devices with a lower resolution, but percentage based systems usually end up with a column that is, for example, 10% of 480px. This causes a vertical split in your text.

One solution to this problem is CSS media queries. Some of the more popular libraries, like the “1140 grid” and the “Bootstrap scaffolding grid”, come with preset media queries. The 1140 grid has a fluid layout, but small screen sizes cause the columns to stack on top of each other.

Fluid grids are tricky to get right…

Bootstrap’s scaffolding grid, on the other hand, incorporates multiple static layouts. As the screen size changes, Bootstrap changes the layout to the one best suited for the current screen size. Once you get to a mobile screen size, Bootstrap loads the same setup as the 1140 grid, a fluid layout with all the columns stacked on top of each other.

What’s wrong with choosing one of these? Well, technically nothing, but they are not tailor-made for your specific app. This forces you to build your app into their grid and work around the framework’s limitations. You can always modify their framework, but you might as well make your own and shave off the unneeded, overhead features.


Introducing Susy

As I mentioned before, Susy is a plugin for the Compass framework that brings a wide array of mix-ins for creating your own CSS grids. You simply specify the default number of columns and a few size options (column width, grid padding, etc), and Susy calculates the correct percentages for your elements. This gives you the power to change the number of columns and their sizes.

You can create three different types of grids: static, fluid and magic.

You already know what static and fluid grids are; let’s take a look at what “magic” grids give you. Magic grids have an elastic outside and a fluid inside. In other words, the outside of the grid (max width) adjusts according to the browser’s default font size (desktop browsers usually have a default of about 16px). The grid’s inside resizes based on the browser’s actual width. This combination gives your site a more consistent look across browsers while still supporting smaller screens.

Susy provides a mix-in called “at-breakpoint”, which allows you to set custom CSS according to the size of the screen. This mix-in accomplishes this feat with CSS media queries. So for example, you can rearrange the columns to stack on top of each other like in the previously discussed frameworks, and you can even remove content that doesn’t fit a mobile device.


Setting Up a Susy Project

I assume you already have Compass installed, but if not, you can refer to Jeffrey’s video series. To install Susy, just open a Ruby command line and type the following:

sudo gem install susy

Next create a Compass project. Type the following:

compass create project_name -r susy -u susy

You should see an info page, detailing how to get started.

Inside the newly created directory, you should see two folders along with a config file. You will edit the files residing in the sass directory; Compass compiles these files to output the final CSS to the stylesheets folder.

To save time compiling the CSS files after each update, you can use Compass’ watch command to make Compass automatically recompile your files every time you save an update. So, in the terminal window type the following command:

compass watch

Compass will now start monitoring and re-compiling the files in the sass folder. Keep in mind that you must keep the terminal window open in order to monitor the folder; if you use the terminal for file editing (i.e. vim), then you need to open another window.


Susy in Action

Now that you have everything setup, let’s take a look at my quick demo. I am going to keep the HTML short because it’s the CSS that we are really here for. The demo is an event guest manager that lists the invited guests and keeps track of who RSVP’d. It’s a simple idea that showcases many of the concepts we discussed.

The Plan

HTML-wise, there will be a header area followed by a row with the name of the event, some controls, and finally the actual list of guests. You can take a look at the image below to better understand the layout.

Here is the entire HTML page for the demo:

<!DOCTYPE HTML>
<html>
	<head>
		<meta name="viewport" content="width=device-width, initial-scale=1" />
		<link href="stylesheets/screen.css" media="screen, projection" rel="stylesheet" type="text/css" />
	</head>
	<body>
		<div class="container">
			<h1 id="header">Plan It! <span class="tagline">Event Guest Manager</span></h1>
			<div id="controls">
				<h3 id="menutitle">Guest List For - John's Wedding</h3>
				<div id="buttons">
					<a id="phonebook" href="#">Add From Contacts</a>
					<a id="newguest" href="#">Add New Guest</a>
				</div>
			</div>
			<table cellspacing="0">
				<thead>
					<tr>
						<th>Name</th>
						<th class="email">Email</th>
						<th class="phone">Phone</th>
						<th class="cell">Cell</th>
						<th>RSVP Status</th>
					</tr>
				</thead>
				<tbody>
					<tr>
						<td>Dave K. Samten</th>
						<td class="email">dsamten@gman.com</td>
						<td class="phone">708-6777</td>
						<td class="cell">360-234-1192</td>
						<td class="buttoncell">
							<a class="unconfirm" href="#" alt="Confirmed">Confirmed</a>
						</td>
					</tr>
					<tr class="alt">
						<td>Bob Renper</th>
						<td class="email">bobren@gman.com</td>
						<td class="phone">537-4267</td>
						<td class="cell">621-124-4294</td>
						<td class="buttoncell">
							<a class="unconfirm" href="#" alt="Confirmed">Confirmed</a>
						</td>
					</tr>
					<tr>
						<td>Kevin D. Turner</th>
						<td class="email">kturn@gman.com</td>
						<td class="phone">942-2674</td>
						<td class="cell">930-654-4144</td>
						<td class="buttoncell">
							<a class="confirm" href="#" alt="RSVP">RSVP</a>
						</td>
					</tr>
				</tbody>
			</table>
		</div>
	</body>
</html>

Susy uses min-width for the media queries by default; so, you start by defining the CSS for the smallest layout and then gradually expand the layout with the increasing screen size. The ‘mobile’ version separates the tagline and buttons onto their own lines, and we make everything fill the width of the page.

I use another Compass plugin, called Sassy Buttons, to generate the buttons’ CSS. It isn’t integral to this demo, but you can install it by typing the following in a terminal:

gem install sassy-buttons

Then add the following line to your config.rb file:

require 'sassy-buttons'

The SCSS

Let’s define the layout. Open _base.scss in the sass folder. This file contains all the import statements and variables that we need later. Replace everything inside that file with the following:

@import "susy";

//if you want to use the buttons plugin
@import "sassy-buttons"; 

//this is the default number of columns
$total-columns: 5; 

//width of each column
$column-width   : 4em; 

//space between columns
$gutter-width   : 1em; 

//space on the right and left of the grid
$grid-padding   : $gutter-width;

//alternative layout breakpoints
$tablet: 8;
$computer: 55em 12;

By itself, a fluid layout is almost as bad as a fixed layout…

The total-columns holds the default number of columns for the smallest display in your layout.

I went with three layouts total: mobile, tablet, and computer. Susy’s breakpoints allow you to do things like setting the min and max sizes for the media queries, and you can even add special support for Internet Explorer. I’m going to keep this example simple and cover just two types.

The tablet breakpoint activates when the screen can fit eight columns. The computer breakpoint activates when the screen is at least 55em wide, and the 12 in $computer: 55em 12; tells Susy to switch to twelve columns.

Now save this file and open screen.scss. Erase everything in the file and import the base file. Let’s also define the main container:

@import "base";

body{ 
	background:#F7F3E8; 
	a{ text-decoration: none; }
	.container{
		@include container($total-columns, $tablet, $computer);

Notice you don’t need the underscore or the file extension when importing the base file. Inside the container class, we use the first Susy mix-in that defines the different layouts for the grid. Then, it’s just regular SCSS for the mobile layout:

		#header{
			font-weight: 700;
			font-size: 72px;
			span{
				font-weight: 300;
				font-size: 18px;
				display: block;
			}
		}
		#controls{
			#buttons{
				margin-bottom: 5px;
				#phonebook{ @include sassy-button("simple", 6px, 14px, #337EC4); }
				#newguest{
					margin-top: 5px;
					@include sassy-button("simple", 6px, 14px, #D93131);
				}
			}	
		}
		table{
			width:100%;
			thead{
				color: #FEFEFE;
				background: #000;
				th{
					text-align: left;
					font-weight:500;
					padding:10px;
				}
			}
			tbody{ 
				border: 3px solid #000; 
				tr{ background: #E5E5E5; }
				tr.alt{ background: #EEEEEE; }
				.buttoncell{
					.confirm{ @include sassy-button("simple", 6px, 14px, #F39B06); }
					.unconfirm{ @include sassy-button("flat", 6px, 14px, #3BA06F); }
				}
			}
			.email{ display: none; }
			.phone{ display: none; }
		}
	}
}

As you can see in the last two lines, I hide the email and phone columns in the table so that the page fits normally on a mobile device. As a best practice, give the user a different way to view the full information (i.e. modal, other page), but I leave that out for the sake of this example’s simplicity.

We now have the basic CSS completed for the mobile website, and we can start modifying the layout with breakpoints. Here is a quick screenshot I took on my iPhone of the mobile version:

Adding Breakpoints

The first breakpoint we need to implement is the tablet version; remember, we must start with the smallest layout first. The tablet size is large enough to put the tagline on it’s own line, and we can also display the email column. Unfortunately, it still isn’t big enough to put the event name and buttons on the same line. Here is the SCSS for this breakpoint:

@include at-breakpoint($tablet){
	body .container{
		#header span{ display: inline; }
		table .email{ display: table-cell; }
	}
}

No ‘magic’ commands here, just standard SCSS inside a Susy mix-in. Here is a screenshot from an iPad of the tablet layout:

Finally, let’s implement the desktop version. We definitely have more than enough room for all the columns; therefore, we indent the table on both sides so that it doesn’t have too much blank space. We also move the buttons onto the same line as the event’s name, aligning it to the right side, in order to center the table (visually, at least). Here is that code:

@include at-breakpoint($computer){
	body .container{
		#controls{
			#menutitle{
				@include span-columns(5);
				margin-top:5px;
			}
			#buttons{
				text-align: right;
				@include span-columns(5 omega);
			}
		}
		table{
			@include prefix(1);
			@include suffix(1);
			.cell{ display: table-cell; }
		}
	}
}

This is the first time we use the span-columns mix-in. Susy takes whatever value you pass to calculate the width percentage of the container. The omega keyword tells Susy that this is the final column in the row. This makes Compass float the column to the right and removes the right margin.

The prefix and suffix mix-ins push the container x amount of columns in from the left and right respectively.

You can now save this file and let compass compile it into CSS. If you added the sassy-buttons plugin after launching the compass watch command, you have to stop the watch command ( shortcut: CTLR-C ) and restart it in order to compile the SCSS.


Closing Thoughts

This is a very brief introduction into Susy. For a more complete list of features, you can visit Susy’s documentation.

I hope you enjoyed this article, and thank you for reading. Like always, feel free to leave any comments or questions in the comments section. You can also contact me on Twitter – @GabrielManricks and I will try to get back to you as soon as possible.

Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • harlley

    How do you calculate 55em as the tablet’s size?

    • http://gabrielmanricks.com/ Gabriel
      Author

      I think I started with the size where the table started clipping and then I worked backwards with some trial and error. Theoretically this can be calculated by multiplying the number of ems with the default font size (I think on the iPad it’s 12px) and adding the gutter and padding widths.

      but honestly you don’t have to be that exact because the grid is fluid-like and tablets resize the content anyways to fit. so as long as your close it should work fine.

  • Ren

    I’ve enjoyed using foundation from zurb.

    • http://twitter.com/SubOrganik Conor Luddy

      Foundation is great but it’s overkill if you just want a grid.

      • http://www.opticgait.net tbartels

        Foundation is modular, you can use just the grids if you want and exclude everything else very easily.

  • shamim

    This is really a great announcement..
    Thanks to share..

  • http://profiles.google.com/aeonbeat Martin Petrov

    I don’t think there’s anything better out there, covering responsive grids and mobile first approach in such a flexible way, so that you can tweak it with ease. Sass, Compass and Susy makes the perfect toolkit. And no bloated code – both html and css! Highly recommended! Also, if you think different, I’d like to be introduced to different practices.

  • http://www.udaantechnologies.com/ web design india

    wonderful announcement……

  • http://twitter.com/danielepolencic Daniele Polencic

    I think the approach works well for small scale websites but it’s terrible ineffective for larger ones. Basically you end up writing three separate websites (mobile, tablet, desktop) rather than just one. Also, modifying an existing style means double checking in all the media queries (is the property declared in the tablet, mobile or desktop section? is it global!?).

    But the worse part comes when someone else (or just yourself few months later) have to modify the existing structure of the website. Because grids are defined in CSS (as mixins), you must understand first how the element’s been defined and then modify not just the HTML but also the CSS. Whereas with grid systems like twitter bootstrap or grid960 you immediately spot how the column behaves and how big it is (e.g class .grid12).

    Lastly, mobile first design means that there are additional assets loaded for desktop/old browser (IE7, IE8 anyone?) that don’t understand media queries, which (depending on your site) could be 80% of your market share. Would you load 80% of the times a media queries polyfiller? That sounds like a lot of HTTP requests. On the other hand, the majority of mobile devices can clearly understand media queries. So, why mobile first?! I understand mobile DESIGN first, but not mobile DEVELOPMENT first.

    I’m very interested to know different opinions.

    • http://twitter.com/sammarkz Sam Markiewicz

      I totally agreed with your comment, as I recently have to deal with Susy for a responsive e-commerce website.
      The choice wasn’t mine, it was imposed, without any concertation with me (and I’m a front-end developer).

      Basically, I’m not a great fan of using grids for DEVELOPMENT, and the only tool/framework that allows me to work decently with that is Foundation by Zurb.
      The main trouble with Susy is that is a very very constraining technology.
      When you say “Basically you end up writing three separate websites”, that’s absolutely true.
      In our project, I had to redefine a complete new grid for mobile, which was a waste of time, and also leads us to a non-digest mobile.css…
      Without mentioning the fact that some parts of the design have been subjected to major changes, due to the use of Susy.

      Another point to highlight is that your breakpoints will be very approximative in fine.
      To me you better have to rely on traditional media queries, since the numbers of devices has considerably increased, and so the number of cases …

      As you mentioned it, maintaining and changing something in the structure will be a pain in the arse in the future.
      Maybe it won’t be for a very basic structure (like a blog, or a simple website with content and not so many graphic fantasies or tricky parts), but for an e-commerce website, or a site that wants to stand outside of the crowd, you can legitimately have some fears.

      For the Mobile first approach, it’s clear that the design has to come first, but to allows a pragmatic development. Which one has to begin approximately at the same time of the design step to avoid great troubles in the end.

      Finally I think that there are not so many options.
      If you want to do the job in a clean way, learn to make it in the clean way.
      It’s always the best solution, and one that costs you the less at different levels.
      But if you want to create prototypes or websites with responsive grids without having too much troubles, the best tool I found yet is Foundation.

      Believing in “magic” tools. It just seems that it’s the zeitgeist…

    • lozandier

      I recommend using IE conditions, conditionally load stylesheets and responsive web design related JavaScript using a variety of ways, and finally implementing more well-thought out media queries.

      The latter alone, considering you’re using SASS, would make those HTTP requests you’re worrying about hardly an issue. Considering the high use of mobile devices, unless you or your client has done the homework related to clients you’re targeting for the project, it’s doubtful that’s the case.

      When it comes to responsive images, I suggest understanding the importance of SVG for illustrations and reading “Retinafy Your Websites and Apps” by Thomas Fuchs. You shouldn’t even really have a need to have multiple versions of even content images if you utilize knowledge provided in the book and other various places throughout the web.

    • http://twitter.com/fazalkhan Fazal Khan

      “I think the approach works well for small scale websites but it’s terrible ineffective for larger ones”

      I beg to differ.

      I’ve used Susy exclusively throughout http://renault.tv . It was actually a lot easier to manage because, if you’re doing it properly (particularly on larger sites) you should try and modularise everything. Therefore you don’t actually code up three seperate sites, you just write a particular rule for the device layout if it requires it.

  • http://twitter.com/qtguru Remy

    Am not attacking the post i think its nice, but this seems like complicating CSS, i think Bootstrap is straight forward but i appreciate the need for introducing more options, but it seems like adding another learning curve to CSS

    • http://twitter.com/JohnHarr92 John Harrington

      Bootstrap is straightforward but leads to bloated css, susy just does the maths and leaves the rest to you…

  • http://profile.yahoo.com/TM7XXVFFY5CLETSQTPINXUQMFY Josh

    Susy is much easier than this I’m going to be doing a video tutorial shortly on my blog after I cover building components with SASS and Compass.

    • http://jitendravyas.com/ Jitendra Vyas

      what is your blog url?

    • http://twitter.com/pattulus Patrick Welker

      I’m also in interested in your upcoming tutorial Josh. Make that a +1 to Jitendra’s question.

  • Barry Reynolds

    What works for Susy and in some of the sites that I’ve built using it, is the simplistic nature of forming the layouts for cross platform support. Sure it’s not totally effective on the largest website, but for customers looking for good WordPress sites built to take on the ever adapting modern web, Susy’s great. I’ll look into inventive ways to integrate it into sites I build on http://www.reynoldsdigital.com and see how effective it is in my workflow.

  • http://twitter.com/pomerla Iskander Shankar

    Thanks to share..

  • Guest

    one m

  • http://twitter.com/anjum121 anjum nawab

    One more freaking Framework :(

    I love working with foundation, but its always good to know what’s new in industry

    • http://twitter.com/JohnHarr92 John Harrington

      nope, susy is NOT a framework…it’s just a tool that makes it a big bit easier to write your own grids, all it’s really doing is making the maths simple!
      That’s why I love susy, foundation is a bloated framework just like the rest, susy is nothing like that.

      • http://www.facebook.com/profile.php?id=520431325 Bobby Iacobelli

        I say bring on the tools and frameworks and cross-platform converters and preprocessors and mv* arch templates and whatever the f yeoman is…take away all that stuff and my workflow would be about 900 times sloppier, less efficient and wouldn’t work very well on most systems…so many people hate on them, and yea, some do suck and have no reason to exist but the rapid progress and workflow perfection is proof of concept of open-source democratic ideals and its just better

  • http://twitter.com/PedrBrowne Pedr Browne

    For anyone reading the comments to gage whether yet another library is worth your time, I’ve been using Suzy for a while and it beats everything else I’ve used hands down. It’s really nicely thought out and although the examples and docs are a bit unfocused, it’s easy to pick up.

  • pixelBender67

    I’ve been using Foundation3, but this looks really nice :D

  • Ramiro

    Great tutorial Thanks