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:
- 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?
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.
- 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.
Simple 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.
Full frameworks
Other frameworks went beyond columns.
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.)
Ben – a little late here, but what do you think of tailoring? If I get Jens Meier right then that’s the key for web frameworks[1]. But I think you and others have advised that there are other priorities too. I see both points but wish this was a little easier.
[1] http://www.oreilly.com/web-platform/free/book-of-html-css-frameworks.csp
Our gallery has over 600 original paintings in the form of hand-painted paintings on canvas (some paintings are also available as prints on canvas and prints on plexiglass). tavlor
Oh! Amazing employment with the editorial . I locate few helps over here related by this post to accomplish my task
nicely. I highly recommend this. Thanks a lot………rushtutor.com
Oh! Amazing vocation with the piece. I hit upon few helps over here related by this post to act my task nicely.
I highly recommend this. Thanks a lot………prepare-for-test.com
Check out another interesting solution – Percentage-based – also working in Safari, Opera: http://coolumns.creatingo.com/
If you want just the most basic features of Cascade Framework, there’s now also Cascade Framework Light ( https://github.com/jslegers/cascadeframeworklight ).
Not to be a “me-too”, but I thought I’d share something I made and find useful. I “merged” toast and skeleton into skeletoast: https://github.com/binaryphile/skeletoast.
If you like either framework, this one is not meant to try to supplant either one of them. I just liked the inline-block method used by toast (no resets, a must with the CMS I use) and its fluidity, but I also liked the features of skeleton (16-columns, nestable, offsets, etc.). Skeletoast has all of it.
I also stripped out the styling to focus on just the grid, with the exception of setting a root font-size.
Thanks for the article and cheers.
Does any of these framworks works loading information dinamically? I’ve seen that some of them (Bootstrap for example) works collapsing layers, now it’s is visible, now not.
That’s not useful for heavyweight webs or webapps. Some recomendation or idea?
Hi, I’d just like to add my CSS framework to this list. It’s called Jeet and it’s a semantic, IE7+, responsive CSS framework that: supports SCSS and/or Stylus; has an easy-to-use npm package; and an awesome mixin that let’s you define column widths with custom fractions like so: #sidebar w(2, 5) #content w(3, 5)
You can check it out at http://jeetframework.com or jump straight to the docs on the Github page: https://github.com/CorySimmons/jeet
That’s one of the things I’ve always hated about Bootstrap and one of the reasons I built Cascade Framework.
Cascade
Framework combines the Bootstrap look-and-feel with a modular
architecture inspired by OOCSS and SMACSS philosophy, allowing you to
pick only those parts of the framework you need and keep your framework
CSS smaller than 5k (minified and gzipped) for projects where you only want the framework’s core features.
Just last weekend, I released a new responsive CSS framework I labeled “Cascade Framework”.
Cascade Framework combines feature richness with modularity,
flexibility and a tiny footprint while maintaining support for old
browsers.
Feel free to check it out at http://jslegers.github.com/cascadeframework/ .
Frameworks aside if you know your responsive grid concepts and understand the process of building responsive CSS, you should checkout this tool that aids you in the process. It basically handles all your CSS conversions: joyresponsivecss.com