LearnA Look at Responsive CSS Frameworks

CSS frameworks have gone responsive, squeezing content into a spectrum of desktop and mobile browsers with varying degrees of success. While any CSS solution for layout is preferable to nested tables, no single solution fits every website. But that hasn’t stopped them from trying.

Not long ago designers who laid out web pages also had to plunge into myriad layers of nested tables, ferreting out that one misplaced </td> or making the same tedious width change across many pages. The challenge today is deciding how layouts, grid-based or otherwise, change with varying browser widths.

The more complicated a page, the more it benefits from a grid system. On the web, CSS-based grid frameworks aid designers by lowering the learning curve from learning how CSS blocks, floats and clears work to learning the framework itself.

Traditional columns are less practical on narrow pages, and most frameworks turn columns into stacked blocks of content. Even advanced frameworks have trouble adapting to smartphones’ 320px – 480 pixel-wide screens. They also have varying definitions of “mobile,” which I found while reviewing 15 responsive grid systems.

Pre-built frameworks get designers up to speed with a limited methodology rather than spending time building an intimate knowledge of CSS positioning. It’s easier to figure out what “.row.span-4” means than figure out codes that each version of every browser agree upon.

Today’s frameworks have an added feature: The ability to change when viewed on mobile devices. I reviewed 15 responsive CSS frameworks to see how each approached the problem of adapting to mobile.

(Skip the lecture — get to the bottom line.)

The landscape

Designers shopping for a framework are likely to see similarities among their options. Every CSS grid layout framework I reviewed followed the same formula:

1. Assign classes that relate to an arrangement of width units to an element.
2. Rows divided into columns.
3. 12-16 columns per row.
4. Designed to fit as many cases as possible.

The last point works both ways. These frameworks require websites to adopt their particular nomenclature. This makes changing frameworks more difficult over time: The more pages are marked with a given framework’s classes, the more have to change if the designer wants to switch. That’s the first reason why choosing the right framework is important.

Tools also influence the medium, and websites’ designs adapt to their framework’s capabilities and limitations. For example:

• Only three frameworks allowed columns within columns.
• Every framework except for two worked on base 12 or 16 columns.
• Lacking vertical alignment, all of the frameworks were technically half grids.
• Some frameworks had offsets, or units of empty space.
• Most frameworks used class values that approximated English.

If this sounds familiar, it’s because many of these features have been around since the beginning. Fundamentally, frameworks resemble table-based layout of yore: Horizontal rows divided into vertical blocks. While this is a semantic improvement, every framework still added layout data to HTML.

It begs the question, what does layout with CSS offer over tables?

Old school

Tables for layout came from the desire to arrange elements on a page with more finesse than left/center/right. Up to 2005 they were the only solution supported by all major browsers at the time. Prior to that, nested tables increased the chances of mistakes and lowered flexibility.

The parallels between frameworks’ and tables’ markup is hard to miss. One could argue that frameworks are more verbose than tables. For example, <div class="row"> is a longer statement than <tr>. Even worse, many frameworks require additional “clears” to mark the ends of rows.

Code-wise, a typical table layout…

<table>
	<tr>
		<td>content</td>
		<td>content</td>
	</tr>
</table>

…closely resembles its equivalent layout in CSS.

<div class="container">
	<div class="row">
		<div class="unit">content</div>
		<div class="unit">content</div>
	</div>
</div>

Both use one element per column, one element per row, and one element to hold the them all. (Officially tables require rows (tr) to reside in thead, tbody or tfoot. But adding these elements is not required.)

How did we get here? CSS frameworks could not have come to be without pivotal changes in web page layout.

1. CSS is reusable. Tables declared their size in HTML itself. That means to change layout across an entire site, designers had to change every HTML file. CSS unifies formatting in a single file from which many HTML documents may get layout information — as long as they use the same nomenclature. A sensible naming scheme is vital for CSS frameworks.
2. CSS has moved on. Tables support background, padding, margin, borders, width and height. CSS did the same, but has since added round corners; the ability to control padding, margin, and borders independently; the ability to measure with ems and points (td only supported pixels and percentages); media queries; the ability to stack if needed (cells in a table row retain their horizontal arrangement). Officially, table cell widths died in HTML4 and have limited support in major browsers.

Table patterns were never easy to come by. But designers don’t want for CSS frameworks.

Simple frameworks

If you’re looking for no-frills layout in a hurry, 10 frameworks will fit the bill.

The 1140 Grid has not been updated “in more than a year” (January 2011 in github) but remains online with an invitation to use it as a starting point for future development. This framework uses a 12-column horizontal grid up to an eponymous width of 1140 pixels.

Responsive Aeon 2.0 includes CSS resets for HTML5 elements, Photoshop and Illustrator templates, and Sublime snippets that contain the CSS framework and sample HTML in their entirety. The framework uses a 12-column grid with a breakpoint to one column at 768 pixels.

Columnal is an offshoot of the 1140 Grid with inspiration from 960.gs and a HTML5 reset from Eric Meyer. This framework uses a 12-column grid with a breakpoint to one column at 768 pixels, and includes one separate stylesheet for debugging and one for Internet Explorer. This download comes with PDF and Illustrator mock-up sheets, and a Balsamiq template.

Gridiculous is a 12-column, up-to-960-pixel-wide framework that allows nested columns — that is, column sets within columns. Unlike other nesting frameworks, however, inner columns have their own 960-pixel break point. Its CSS file is short, only 4,300 characters including comments. It’s easy to figure out.

Ingrid, while flexible, does not itself include breakpoints, media queries or min/max widths. But it does come with a sample file illustrating how its fluid-width columns may be set to collapse. By “sample” I mean “ASCII art” in a markdown file.

Responsive Grid System by Denis LeBlanc was the first of two named “Responsive Grid System.” This framework comes in 12, 16, or 24 fluid column varieties. The stylesheets are short and easy to decypher. I mean, ridiculously simple: Columns declare their respective percentages. That’s about it.

Responsive Grid System by Graham Miller was the second of two named “Responsive Grid System”. Where most frameworks used either base-12 or -16 column grids, this framework included a range of columns per row from one through 12. Need seven equal columns? No problem. RGS also took the unique approach of separating each set of columns into its own file. Don’t need seven equal columns? Don’t call its CSS document.

Titan is a relatively sophisticated framework whose in-CSS documentation went beyond the call. A table of contents and well-marked divisions made this framework easy to learn. That’s handy because the download did not include a sample HTML document. Its 12 and 16 column variations break to one column under 768 pixels wide.

Toast is simple. Really simple. Twelve fluid columns, a wrapper, and Bob’s your uncle. In a separate stylesheet, though, it includes styles to manage a site’s baseline, or vertical grid. Toast’s column styles have an interesting quirk: Text inside the container (“.grids”) but not inside a column (“.grid-#”) became illegible due to a “letter-spacing: -.25em” fix for inline blocks.

All of the frameworks above had a breakpoint that changed layouts to one column for browser widths under 768 pixels — except for Responsive Grid System (Graham Miller), whose breakpoint was at 480px; Toast, 700px; and Ingrid, which only had “breakpoint examples” in a demo file.

Full frameworks

Other frameworks went beyond columns.

Base: Styling itself as super simple, Base nonetheless sets typography rules for major HTML elements (headings, paragraph, strong, em, links, blockquotes, code, etc). Other additions alternate table row backgrounds and determine which levels of nested lists have certain types of bullets and numbering. Although the grid framework and typography styles share the same CSS file, that file is organized well enough to make changes (or removal) easy.

Foundation: Signs of popular frameworks include templates and case studies. Foundation has both. Along with a responsive grid, the Foundation by Zurb download includes jQuery-based slideshow and tabs. Like most frameworks, Foundation drops to to one column when the browser is less than 768 pixels wide.

Gumby: Like its flexible namesake, the Gumby framework by Digital Surgeons includes user interface widgets such as drop-down navigation and sub-navigation bars, tabs, formatted forms and tables, and various jQuery-based buttons.

Kube: Kube by Imperavi’s stylesheet included definitions for type, forms, buttons and tables — convenient for designers who appreciate Kube’s particular taste. In addition to straight CSS, Kube is also available in LESS.

Skeleton: Of the frameworks with widgets and extras, Skeleton by Dave Gamache has the easiest-to-read CSS. Although its stylesheets include typography, form, table and button declarations, Skeleton does not claim to be a UI framework. Its non-grid styles are kept in separate CSS files, making it easy to retask. Skeleton comes built into themes for WordPress and Drupal.

Twitter Bootstrap: Bootstrap makes its learning curve worth the effort. Its extensive capabilities can be customized, although designers wary of option overload may want to start with the simplified “getting started” download. What it lacks in stylesheet comments Bootstrap makes up in online documentation and sample files. Bootstrap’s UI widgets include popups, navigation bars, modal boxes, progress bars, and slideshows.

In Conclusion: Which one?

I tested these frameworks with a file of greeked text organized by two levels of <div>s. Every framework I tried claimed to be mobile-friendly, or at least responsive. But all approached mobile design from a desktop standpoint: Smartphones get one column.

Fastest setup: Toast took me the least time to implement, with Aeon a close second. Ingrid and Columnar each took a few more minutes to read and understand, but I could use both well enough to rearrange page layout in five minutes apiece.

Most options:Twitter Bootstrap had the most widgets and interface options. Foundation was no less capable, although its addons were just that: Separate projects working together through common conventions.

Fastest integration: The Skeleton framework’s options were the easiest to ignore. I could remove and reinstate its widgets in a snap, and its CSS was marked well enough for designers of moderate of experience to get started quickly. Skeleton’s creators even link to WordPress and Drupal themes that use its nomenclature, as well as a Ruby Gem (v3.1 and later).

Best long-term support: It’s hard to say how any digital project will hold up in the future. But Bootstrap, Gumby, Foundation, and Kube are all backed by companies with more than one professional product in the marketplace.

Choosing a CSS framework (or inventing your own, or adapting what exists) is not an easy decision. There may not be one right answer for everyone, there are few wrong answers for everyone. Think of it this way: At least they’re not tables.

(Update: Removed incorrect names as pointed out in the comments.)