Here’s a little CSS trick I came up with while developing the stylesheet for our new website at San Jose Public Library.  I hope it can assist other web teams with quicker development strategies as they try new things on their library websites.

(UPDATE- see the bottom of this post for a vastly improved version of what I’m writing about, by Brad Czerniak of Canton MI.  This seems to be the beauty of blogging about such topics: there’s always someone out there who knows much more than I do!  Thank you Brad for the great ideas, and sorry your comment got caught in the spam filter-)

When I started at SJPL, I was completely sold on making websites with fixed-width proportions.  This means that your web site doesn’t scale and stretch when you expand and contract your browser window, instead it is optimized to display well for a specific screen width.  I’d discovered a few slick grid formats other designers had made and shared that were ready for the picking.  Using these templates I’d become pretty handy at creating standard layouts quickly.  So when our web team decided we wanted to make our entire site fluid, I sort of gave a *gulp*, knew it was the right direction to move in, and dove into something new.

To be clear, fluid layouts declare percentages to determine the size of areas on your screen, rather than pixel widths.  This is what makes them expand and shrink.

We started with simple layouts at SJPL. By declaring some column widths of 100% and 50% and 33% we got off to a great start, but we discovered that a complicated library website actually can actually have a lot of different layouts.  I find it kind of sad that interface and layout design frequently sacrifice unique and interesting approaches to design problems in the name of usability science.   The reductive process of developing and optimizing stylesheets coupled with the need to make access to information easy rather than engaging and satisfying is a disappointment.  I’m not saying that library websites should be Picassos, indeed they are utilitarian and should function well.  They can still look awesome though, and they can challenge their users by playing unique layouts against simple architectures.

So here’s what I have to offer you, friends: a development stylesheet for rapid prototyping fluid layouts so that you do not succumb to all of the boredom of usability science without trying some wacky, complicated designs first.  It will also allow you design collaboratively in a group with ease.  The framework operates largely the same way that static grid systems do, and I’m telling you, this makes it insanely easy to play around.  I have to assume other designers have been taking this same simple approach since like 1993 or something, but I felt like I invented it when it dawned on me.

Copy the whole file here.  The stylesheet goes from 1% to 100% calling out every single class.  This way you don’t have to think about creating your CSS classes as you move content around a page because you know you can just call them out and they already exist.  Then, when your site is done, delete the classes you didn’t use and you are set to go.

So, for example here’s a 12% column:
.col-12 {float: left; width: 12%; height:auto; background:none; padding:0px;}

Or here’s a 76% column:
.col-76 {float: left; width: 76%; height:auto; background:none; padding:0px;}

The format remains the same, 1-100.

Have fun with it!

—————————

The updated, better version:

The CSS repeats a lot of the same properties. Why not something like this?:

.col{float: left;height:auto;background:none;padding:0px;}
.col-1{width:1%;}
.col-2{width:2%;}
…

Then use multiple classes for columns, like

<div>Filler content</div>
For a true grid, why not start with an already-made fluid grid system? In the quick survey I took, the newgoldleaf fluidgrid system looks the best. It really does snap to a nice grid.

Don’t forget to set absolute min-width and max-width on the columns after prototyping! Otherwise, you run into overflow and float drop issues.

You could also forgo an HTML doctype declaration (thereby putting the browser in quirks mode) to make working with the box model easier in a fluid layout – allowing for margins, padding, and borders without junk markup. CSS3 will allow the best of all worlds with box-sizing. Not sure compatibility’s there enough yet (damn you, IE7!). Another legit option would be to normalize whitespace, so all columns would have the same percent-based padding and margin. Then you could still count to 100-ish% while keeping to sound layout principles.

I’m not sure what purpose the background property serves in the CSS, but I recommend separating strictly layout decs from style decs when using a grid system (and in other circumstances). That way you can give a container a background without mucking with selector specificity or !important.

Also, height:auto; is the default value for height, so including it is redundant. If you run into height, clearing, and float drop issues, try floating the container; often works a charm.

Criticisms of similar grid systems are pretty easy to find. One problem is that the classes aren’t semantic: they don’t describe the html content. From a templating perspective, it makes sense to give elements semantic names, then put selectors for those elements in a CSS file and use firebug to prototype style them on the fly. I try to use tag-level selectors and html5 tags to get most of the way there, which can make a site more consistent when done correctly.

There’s also a legitimate argument for your first assertion: fixed-width layouts. With monitor resolutions increasing, mobile devices pretending to have high resolutions, and browsers using page rather than text zooming as the default, fixed-width layouts make for consistent, attractive, hassle-free sites.