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.
Designers shopping for a framework are likely to see similarities among their options. Every CSS grid layout framework I reviewed followed the same formula:
- Assign classes that relate to an arrangement of width units to an element.
- Rows divided into columns.
- 12-16 columns per row.
- 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?
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.
- 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.
- 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.
If you’re looking for no-frills layout in a hurry, 10 frameworks will fit the bill.
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.
Other frameworks went beyond columns.
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.)